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

[Ilya Biryukov via cfe-dev]

Since this popped up, I wanted to add a bit to the point made in the syntax
trees doc.

Matchers for syntax trees have the following downsides:
- would incur a maintenance burden,
- will lack semantic information (at least some of it, e.g. implicit casts),
- may not be as helpful in some use-cases (syntax trees already aim to
provide an alternative interface to the AST that is simpler to use for some
use-cases, something that AST matchers also try to do),
- they incur both runtime and compile-time cost.

However, matchers are also a DSL for pattern-matching the parse tree in
C++. In this sense they could also be useful for syntax trees.
Syntax trees are also much more regular than the AST and I believe matchers
for syntax trees could even be auto-generated, so they can potentially be
added there in the future.

On Sat, Dec 21, 2019 at 12:03 AM Stephen Kelly <steveire at gmail.com> wrote:

>
> Matchers are orthogonal to Syntax Trees as laid out in that document:
>
> ```
> Will we end up needing to reinvent matchers for this representation?
>
> **We want to avoid this.**
>
> Matchers are a complicated beast and having a separate set of those for
> syntax trees would be unfortunate. Moreover, syntax trees lack the semantic
> information that the users of AST matchers often rely on. If one wants to
> take advantage of the concept of matchers and syntax trees, they have
> options to do so based on existing implementation of ASTMatchers, e.g. they
> could:
>
>    1.
>
>    use ASTMatchers to find interesting Clang AST nodes,
>    2.
>
>    find their syntax tree counterparts,
>    3.
>
>    apply transformations to syntax trees.
>
> ```
>
>
> Thanks,
>
> Stephen.
> On 20/12/2019 22:02, Gábor Horváth wrote:
>
> Hi!
>
> I like the idea of making writing tools/prototypes easier. But if the goal
> is to get rid of invisible nodes when matching I wonder if this would
> somewhat overlap with syntax trees [1]. Adding Dmitri and Ilya in case they
> have an opinion on that.
>
> Cheers,
> Gabor
>
> [1]:
> https://docs.google.com/document/d/161XftOcF-ut1pGQr5ci9kXd_y0jRQl3y9sVyvuEkLDc/edit#heading=h.cwnlr9q7jmlp
>
> On Fri, Dec 20, 2019 at 1:06 PM Aaron Ballman via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Fri, Dec 20, 2019 at 4:01 PM Stephen Kelly via cfe-dev
>> <cfe-dev at lists.llvm.org> 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.
>>
>> I'm generally in favor of this path forward. I think this is the
>> correct default and allows a more gentle introduction to AST matchers
>> for people new to the project (which helps with introducing new
>> clang-tidy checks) while still allowing people who need to get into
>> the nitty gritty details of the AST to do so as needed. Thank you for
>> the efforts!
>>
>> CCing Manual, Alex, and Sam because they do a lot of work on the
>> matcher interfaces as well.
>>
>> ~Aaron
>>
>> >
>> > 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
>>
>

-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200113/c31771bd/attachment.html>