[PATCH] D113917: Add infrastructure to support matcher names.
James King via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Nov 15 10:31:01 PST 2021
jcking1034 added inline comments.
================
Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1021
+ std::string getName() const override {
+ return "HasOverloadedOperatorNameMatcher";
----------------
Here and below, we have the option to use the name of the matcher (for this, we could use "hasOverloadedOperatorName" instead). However, some of these classes are used in multiple matchers. For example, `HasOverloadedOperatorNameMatcher` is used in both `hasOverloadedOperatorName` and `hasAnyOverloadedOperatorName`, which I'm a bit concerned about.
================
Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:1409
return BindableMatcher<T>(
- makeAllOfComposite(InnerMatchers).template dynCastTo<T>());
+ makeAllOfComposite(InnerMatchers).template dynCastTo<T>(),
+ makeMatcherNameFromType<InnerT>());
----------------
@ymandel suggested an alternate implementation where we instead pass the matcher name to `makeAllOfComposite`, which then passes the name to `constructVariadic`, to avoid making changes to `BindableMatcher`. I may look into this again, but my previous attempts to try this approach seemed messy due to the fact that these functions are used in a few different places, and because `makeAllOfComposite` handles cases with 0 or 1 inner matchers without constructing a variadic matcher.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113917/new/
https://reviews.llvm.org/D113917
More information about the cfe-commits
mailing list