[clang-tools-extra] r347520 - A bit of AST matcher cleanup, NFC.

Alexander Kornienko via cfe-commits cfe-commits at lists.llvm.org
Sun Nov 25 06:59:56 PST 2018


On Sun, Nov 25, 2018 at 1:52 PM Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Sat, Nov 24, 2018 at 9:43 PM Alexander Kornienko via cfe-commits
> <cfe-commits at lists.llvm.org> wrote:
> >
> > Author: alexfh
> > Date: Sat Nov 24 18:41:01 2018
> > New Revision: 347520
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=347520&view=rev
> > Log:
> > A bit of AST matcher cleanup, NFC.
> >
> > Removed the uses of the allOf() matcher inside node matchers that are
> implicit
> > allOf(). Replaced uses of allOf() with the explicit node matcher where
> it makes
> > matchers more readable. Replace anyOf(hasName(), hasName(), ...) with
> the more
> > efficient and readable hasAnyName().
>
> Would it make sense to have a check under the llvm module for this
> coding pattern?
>

Probably yes, but I wouldn't be too optimistic about the positive impact of
that check compared to the cost of creating and supporting it.

If someone has a large enough chunk of time they could devote to improving
clang-tidy performance, there was an interesting idea about optimizing AST
matchers at runtime. E.g. currently `unless(isInTemplateInstantiation())`
matchers go up the ancestor chain, but a more efficient implementation
could just skip traversal of template instantiations for the matchers that
have the `unless(isInTemplateInstantiation())` constraint. To implement
this, the matchers framework would need to analyze the matchers and rewrite
them (instead of just passing control to them).


>
> ~Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20181125/4cd01565/attachment.html>


More information about the cfe-commits mailing list