[cfe-dev] RFC: Easier AST Matching by Default

[Yitzhak Mandelbaum via cfe-dev]

I hit the same behavior and I assumed it was a bug, not a feature, of the
implicit-skipping traversal. Compare to a non-template construction:
```
        template <typename T>
struct MyTemplate {
MyTemplate(int i) {}
};

struct S { S(int x, int y); };
void foo() {
MyTemplate<char> mt(123); // <- NO match
S s(3,4); // <- Match
}
```
The non-template one matches.

+1 to a more subtle representation of the AST (like graying) instead of
hiding parts of it.

On Tue, Jun 16, 2020 at 12:23 AM Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Mon, 15 Jun 2020 at 21:16, Richard Smith <richard at metafoo.co.uk> wrote:
>
>> On Mon, 25 May 2020 at 14:56, Stephen Kelly via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On 20/12/2019 21:01, Stephen Kelly via cfe-dev wrote:
>>> >
>>> > Hi,
>>> >
>>> > (Apologies if you receive this twice. GMail classified the first one
>>> as
>>> > spam)
>>> >
>>> > Aaron Ballman and I met by chance in Belfast and we discussed a way
>>> > forward towards making AST Matchers easier to use, particularly for
>>> C++
>>> > developers who are not familiar with the details of the Clang AST.
>>> >
>>> > For those unaware, I expanded on this in the EuroLLVM conference this
>>> > year, and then expanded on it at ACCU:
>>> >
>>> >   https://steveire.wordpress.com/2019/04/30/the-future-of-ast-matching
>>> >
>>> > One step in the process of getting there is changing the default
>>> > behavior of AST Matchers to ignore invisible nodes while matching
>>> using
>>> > the C++ API, and while matching and dumping AST nodes in clang-query.
>>> >
>>> > I think this is the most important change in the entire proposal as it
>>> > sets out the intention of making the AST Matchers easier to use for
>>> C++
>>> > developers who are not already familiar with Clang APIs.
>>> >
>>> > To that end, I've written an AST to motivate the change:
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/17Z6gAwwc3HoRXvsy0OdwU0X5MFQEuiGeSu3i6ICOB90
>>> >
>>> >
>>> > We're looking for feedback before pressing forward with the change. I
>>> > already have some patches written to port clang-tidy and unit tests to
>>> > account for the change of default.
>>>
>>>
>>> This change is now in master.
>>>
>>
>> Is this change responsible for
>> https://bugs.llvm.org/show_bug.cgi?id=46287 ? If so, I think the current
>> behavior is very confusing, and seems harmful. By default, a
>> cxxConstructExpr matcher no longer matches all CXXConstructExprs, which
>> seems very strange and surprising, and likewise it's alarming that an AST
>> dump from clang-query no longer correctly dumps the AST.
>>
>> Perhaps as an alternative, we should not skip implicit nodes when trying
>> to match a node that might be implicit (analogous to how Type::getAs steps
>> over sugar nodes except when looking for that type sugar node),
>>
>
> To be clear: the behavior I think we should consider is that we consider
> whether each implicit node matches our matcher before stepping over it. So
> (for example) an (implicit) ImplicitCastExpr wrapping an (implicit)
> CXXConstructExpr wrapping an IntegerLiteral would be matched by a
> cxxConstructExpr() matcher, but would also be matched by an
> integerLiteral() matcher.
>
>
>> and instead of hiding implicit nodes in the AST dump we should dim them
>> out but still show them?
>>
>>
>>> clang-query has also been updated to allow setting the traversal mode.
>>> eg:
>>>
>>>    set traversal AsIs
>>>
>>> Since the original RFC I also added clang-query support to godbolt.org,
>>> so you can experiment with it there instead of my personal instance of
>>> compiler-explorer:
>>>
>>>    https://gcc.godbolt.org/z/uwTgZS
>>>
>>> If anyone watched my talk from EuroLLVM linked in my blog above, I am
>>> interested in feedback to know which feature I presented there you would
>>> most like to see upstreamed.
>>>
>>> Thanks,
>>>
>>> Stephen.
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200617/1c8b5ba0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3854 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200617/1c8b5ba0/attachment-0001.bin>