[PATCH] Prevent LoopConvert from shadowing already defined variables with the same name as the loop variable.

[Manuel Klimek]

On Mon, Jun 17, 2013 at 3:06 PM, Edwin Vane <edwin.vane at intel.com> wrote:

>
>
> ================
> Comment at: cpp11-migrate/LoopConvert/VariableNaming.cpp:111
> @@ +110,3 @@
> +  while(DeclAncestor != NULL) {
> +    if (const TemplateDecl *T = dyn_cast<TemplateDecl>(DeclAncestor)) {
> +      // Check that the symbol is not a template parameter of the current
> ----------------
> Manuel Klimek wrote:
> > Edwin Vane wrote:
> > > I think we could get away with just using DeclContexts directly and
> not making a whole DeclAncestor map. The information being stored in that
> map is just a replication of what's available by moving up the DeclContext
> chain.
> > +1. Also, if you have some declaration reference in your statement at
> whose level you're trying to insert, you could get from that declrefexpr to
> the decl, and then get up the declcontext chain.
> >
> > Also, I'd be interested why using getParent from ASTContext doesn't give
> you what you want (and you can even use that with hasAncestor to directly
> get to the decl you're interested in from the matcher without the need to
> drill through all this yourself).
> I think the not using ASTContext's parent map is my fault. I suggested
> trying to use RevereseAST since this transform was already populating a
> kind of parent map. I figured why incur the cost of constructing that map a
> second time. But perhaps it is better to use after all?
>

I noticed on the other mail thread that you'll probably want the "lookup
parent" from the DeclContext, so I think to simulate unqualified lookup we
don't need a parent map at all (apart perhaps from noticing that we're in
the right "branch" where there are multiple parents for the same statement).

Cheers,
/Manuel


>
>
> http://llvm-reviews.chandlerc.com/D950
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130617/4adbf48b/attachment.html>