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

[Manuel Klimek via Phabricator via cfe-commits]

klimek added a comment.

In D56444#1351056 <https://reviews.llvm.org/D56444#1351056>, @aaron.ballman wrote:

> In D56444#1350849 <https://reviews.llvm.org/D56444#1350849>, @JonasToth wrote:
>
> > In D56444#1350746 <https://reviews.llvm.org/D56444#1350746>, @sammccall wrote:
> >
> > > @klimek: would it be better to preserve the odd behavior of the `functionDecl()` matcher, and add a new `functionOrLambdaDecl()`? It seems too surprising to me.
> >
> >
> > We can change the clang-tidy check as well. I think lambdas should be considered functionDecls, shouldnt they? WDYT @aaron.ballman ?
>
>
> I think it depends on whether we want the AST matchers to match what the user wrote (syntax) or how the program behaves (semantics). If the user writes a lambda, they did not syntactically write a function declaration and so it makes sense for `functionDecl()` to not match. However, the semantics of a lambda are that they act as a functor (in effect) which includes a class declaration, a function declaration for the function call operator, conversion operators, etc and so it does make sense for users to want to match those semantic components. Given that, I kind of think we should have functionDecl() match only functions, and give users some other way to match the semantic declarations in a consistent manner. Alternatively, we could decide semantics are what we want to match (because it's what the AST encodes) and instead we give users a way to request to only match syntax.


The problem is that while I agree it would be nice if we matched either exactly the semantic or syntactic form of the code, the reality is that we match whatever the AST represents when we visit all nodes. Instead o f promising folks something that we can't hold (because nobody has time to fully check which matchers will match which form), I think telling people that we match the AST is the more honest and less surprising result in the end.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56444/new/

https://reviews.llvm.org/D56444