[PATCH] D56444: [AST] RecursiveASTVisitor visits lambda classes when implicit visitation is on.

[Stephen Kelly via Phabricator via cfe-commits]

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