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

[Dmitri Gribenko via cfe-dev]

On Sat, Jan 18, 2020 at 4:09 PM Aaron Ballman <aaron at aaronballman.com>
wrote:

> FWIW, I think the proposed solution is a valuable goal.


Goals should not be specified in terms of solutions, because given such
framing, alternatives can't be considered. XY problem etc.

> Clang codebase does not have many matchers that are combinations of
> existing matchers, but code that uses Clang as a library (and often written
> by engineers who are not compiler experts and just need to get some
> refactoring done) does that very often in my experience working at Google.
>
> clang-tidy uses a fair amount of matchers that are combinations of
> existing matchers, but they're localized to the individual checks.


Like I said, that is the case in the Clang codebase. However, my experience
working at Google is different -- most often people compose existing
matchers instead of defining new ones using AST_MATCHER.

> Syntax trees will be used in ClangTidy once they are more fleshed out.
>
> Is this a hope, or was this a decision made already?
>

It is a direction towards which we are building libraries like Stencil,
Transformer, Syntax trees. We can't say that we made a decision to use them
in ClangTidy, because obviously not all of the infrastructure is there, so
we can't evaluate it and make a justified decision. However, we are
building these libraries hoping that they will make common refactoring and
linting tooling (like ClangTidy) more accessible for novices, and easier to
implement even for experts. If we didn't think that could be the case, we
would not be building these libraries.

> It instantly creates a huge testing gap for existing AST matchers (which
> we currently test only in one mode). It also creates traps for existing
> code that will be able to start accidentally calling existing matchers in a
> traversal mode that they were not designed for.
>
> I think the testing gap can be solved with software solutions
> (judicious use of macros and/or templates). The traps for existing
> code are a bit of a concern, but truthfully, no more of a concern than
> use of StringRef is.


It is very different: to catch misuses of StringRef, we already have ASan.

If the composed matcher is publicly exposed, it's
> something the author definitely has to account for. If the composed
> matcher is private to a particular check or other usage (which is the
> majority case as best I can tell),


Correction: the majority case in llvm-project.git.

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/20200122/0d4c7c77/attachment.html>