[cfe-dev] LoopConvert shadowing variables

[Bernal, Ariel J]

I did try getLookupParent() and I get the same results as getParent(). The problem that I found by using DeclContext it that all VarDecls within the same FunctionDecl share the same DeclContext even if they belong to different CompoundStmts.
I also tried using ASTContext.getParents() which gives more information that DeclContext but I still agree with Doug that I should be able to get the information from DeclContexts.

Airel

From: Douglas Gregor [mailto:dgregor at apple.com]
Sent: Monday, June 17, 2013 12:30 PM
To: Manuel Klimek
Cc: Bernal, Ariel J; clang-dev Developers
Subject: Re: LoopConvert shadowing variables


On Jun 17, 2013, at 12:29 AM, Manuel Klimek <klimek at google.com<mailto:klimek at google.com>> wrote:


+cfe-dev

On Fri, Jun 14, 2013 at 9:48 PM, Bernal, Ariel J <ariel.j.bernal at intel.com<mailto:ariel.j.bernal at intel.com>> wrote:
Manuel, Douglas

I'm working on a patch to prevent LoopConvert for shadowing variables  http://llvm-reviews.chandlerc.com/D950  but I don't feel like it's the right solution. Maybe you could shed some light on this.

The first loop goes over CompoundStms and we look for VarDecls that could match the name of the new variable until we reach the FunctionDecl then the next loop goes over Decls to get any VarDecl/FieldDecl/ParamVarDecl...  defined in a parent context.

Unfortunately DeclContext::getParent doesn't return the parent Decl when it comes to templates but I think it could be possible  to use DeclContext instead of using a  Decl-Decl map to reverse the AST.

Added some comments to the review thread. Also, for trying to simulate the unqualified lookup, did you also try getLookupParent()?

Regarding templates, note that statement nodes are shared between the "model" CXXRecordDecl formed by the template definition and containing lots of dependent types and the ClassTemplateSpecializationDecl, which you probably want. So it's important that the first declcontext you get to from the statement where you want to insert the declaration is the one created by the ClassTemplateSpecializationDecl.

Statement and expression nodes in the instantiation will only be shared between the template definition and template instantiation when there are no dependent expressions, types, or declarations anywhere in the statement/expression. A declaration in a template is always instantiated, and will have the instantiation as its DeclContext. There should be enough information in the DeclContexts to conservatively determine whether a newly-introduced variable will shadow an existing variable.

            - Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130617/dd27e680/attachment.html>