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

[Dmitri Gribenko via cfe-dev]

On Fri, Jan 10, 2020 at 4:34 PM Aaron Ballman via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I've not seen much to suggest the community is not in favor of this
> direction, so I think you're all set to post patches for review. If
> there are community concerns, we can address them during the review
> process. Thank you for working on this!
>

Sorry, I just came back from vacation. I'm not sure if it is a good idea,
in particular, for the following reasons:

- The document specifies the goals in terms of a solution: "Goal: Users
should not have to account for implicit AST nodes when writing AST
Matchers".

- The complexity for implementers (although it also applies to
https://reviews.llvm.org/D61837, which landed a while ago, and I didn't see
it). Allowing to run the same matcher in multiple modes increases our
support and testing matrix.

- The complexity cliff for users. Many non-trivial matchers need to
explicitly manage implicit AST nodes.

- The cost of ClangTidy. ClangTidy runs all matchers simultaneously in one
AST traversal. If we implement implicit/no-implicit modes as separate AST
traversals, ClangTidy would need to run two traversals, one for "easier"
matchers (skipping implicit code), and one for "expert" matchers
(traversing implicit code). We would also need to build two parent maps.

My best suggestion is to investigate implementing AST Matchers for syntax
trees, and allow jumping between syntax and semantic nodes in one matcher
-- to match syntax first, and then validate the necessary semantic
constraints.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200113/8dda97f8/attachment-0001.html>