steveire added a comment. In D56444#1351182 <https://reviews.llvm.org/D56444#1351182>, @steveire wrote:
> In D56444#1351150 <https://reviews.llvm.org/D56444#1351150>, @sammccall wrote: > > > In D56444#1351130 <https://reviews.llvm.org/D56444#1351130>, @steveire > > wrote: > > > > > In D56444#1351125 <https://reviews.llvm.org/D56444#1351125>, > > > @aaron.ballman wrote: > > > > > > > if the location isn't somewhere in user code, then don't consider the > > > > node or its children for traversal. However, that may be insufficient > > > > and equally as mysterious behavior. > > > > > > > > > That is exactly what I've implemented. I skip invisible nodes in matching > > > and dumping: > > > http://ec2-18-191-7-3.us-east-2.compute.amazonaws.com:10240/z/EuYjAn > > > > > > So what happens when someone asks about the parent of an invisible node? > > > > e.g. `match(hasParent(decl().bind("parent")), X, Ctx)` where X is the > > `operator()` function of a lambda class. (This is basically the case in the > > bug that this patch fixes) > > > Assuming that whether to skip invisible nodes is part of the `Ctx`, the `X` > would simply not be in context, just like if the `X` were not in the > `TraversalScope` of the `Ctx`. Note that as I have prototyped it, the system is perhaps too-eager, not representing the FunctionDecl (or the ParmVarDecls) at all: http://ec2-18-191-7-3.us-east-2.compute.amazonaws.com:10240/z/tTEjs3 I know what the fix is, and the result will probably be something like TranslationUnitDecl 0x5604ea6343e8 <<invalid sloc>> <invalid sloc> `-FunctionDecl 0x5604ea670470 <<source>:1:1, line:4:1> line:1:5 main 'int (void)' `-CompoundStmt 0x5604ea69b0e0 <col:12, line:4:1> |-DeclStmt 0x5604ea671260 <line:2:3, col:30> | `-VarDecl 0x5604ea6705b0 <col:3, col:29> col:8 used l 'class (lambda at <source>:2:12)':'class (lambda at <source>:2:12)' cinit | `-LambdaExpr 0x5604ea670c60 <col:12, col:29> 'class (lambda at <source>:2:12)' | |-ParmVarDecl 0x558298e6c4b8 <col:15, col:19> col:19 used param 'int' | `-CompoundStmt 0x5604ea670990 <col:16, col:29> | `-ReturnStmt 0x5604ea670978 <col:18, col:25> | `-IntegerLiteral 0x5604ea670838 <col:25> 'int' 12 `-DeclStmt 0x5604ea69b0c8 <line:3:3, col:18> `-VarDecl 0x5604ea671310 <col:3, col:17> col:9 fp 'int (*)(void)' cinit `-DeclRefExpr 0x5604ea69af00 <col:17> 'class (lambda at <source>:2:12)':'class (lambda at <source>:2:12)' lvalue Var 0x5604ea6705b0 'l' 'class (lambda at <source>:2:12)':'class (lambda at <source>:2:12)' and ``parmVarDecl(hasName('param'), hasParent(lambdaExpr()))` would be true, as you would expect from reading the AST. This is of course subject to change and subject to review. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56444/new/ https://reviews.llvm.org/D56444 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
