Adds a utils matcher called hasAnyListedName to alleviate all the hackery using the hasAnyName matcher with types that are already vector<string>
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clang-tidy/utils/Matchers.cpp | ||
---|---|---|
18 | This matcher sounds generally useful. I think it would be better placed in ASTMatchers.h, WDYT? Can we make it an overload of hasAnyName? |
clang-tools-extra/clang-tidy/utils/Matchers.cpp | ||
---|---|---|
18 | hasAnyName is a const variable who's type is VariadicFunction so it can't be overloaded unfortunately. I personally didn't want it in ASTMatchers.h as its mainly useful for clang-tidy checks that load in configurations. It doesn't have a place in say clang-query. |
clang-tools-extra/clang-tidy/utils/Matchers.cpp | ||
---|---|---|
18 |
I thought we had facilities to declare polymorphic matchers that could help here.
A lot of user-defined tools are quite similar. |
clang-tools-extra/clang-tidy/utils/Matchers.cpp | ||
---|---|---|
18 | Polymorphic matchers are matchers that can match against different types of nodes, what we want here is match against one type of node, but different overloads. I am thinking though that With some nifty retooling of VariadicFunction you could possible change it so that you can call its operator() with types that are convertible to its ArgT. However that is a deep rabbit hole to go down for the purpose of what this patch is trying to do |
clang-tools-extra/clang-tidy/utils/Matchers.h | ||
---|---|---|
53–55 | We could change all checks to use the other overload and drop this one (and the utils::options::parseStringList() call in each check's constructor). WDYT? |
clang-tools-extra/clang-tidy/utils/Matchers.h | ||
---|---|---|
53–55 | I'm not sold on that, I'd like the conventions of all checks to be the same wrt option lists, however those option lists aren't only used for names of decls. |
clang-format: please reformat the code