When creating clang-tidy checks, it is common to extract parts of AST Matcher expressions to local variables. I expanded on this in a previous blog.
auto nonAwesomeFunction = functionDecl(
unless(matchesName("^::awesome_"))
);
Finder->addMatcher(
nonAwesomeFunction.bind("addAwesomePrefix")
, this);
Finder->addMatcher(
callExpr(callee(nonAwesomeFunction)).bind("addAwesomePrefix")
, this);
Use of such variables establishes an emergent extension API for re-use in the checks, or in multiple checks you create which share matcher requirements.
When attempting to match items inside a ForStmt for example, we might encounter the difference in the AST depending on whether braces are used or not.
#include <vector>
void foo()
{
std::vector<int> vec;
int c = 0;
for (int i = 0; i < 100; ++i)
vec.push_back(i);
for (int i = 0; i < 100; ++i) {
vec.push_back(i);
}
}
In this case, we wish to match the push_back method inside a ForStmt body. The body item might be a CompoundStmt or the CallExpr we wish to match. We can match both cases with the anyOf matcher.
auto pushbackcall = callExpr(callee(functionDecl(hasName("push_back"))));
Finder->addMatcher(
forStmt(
hasBody(anyOf(
pushbackcall.bind("port_call"),
compoundStmt(has(pushbackcall.bind("port_call")))
))
)
, this);
Having to list the pushbackcall twice in the matcher is suboptimal. We can do better by defining a new API function which we can use in AST Matcher expressions:
auto hasIgnoringBraces = [](auto const& Matcher)
{
return anyOf(
Matcher,
compoundStmt(has(Matcher))
);
};
With this in hand, we can simplify the original expression:
auto pushbackcall = callExpr(callee(functionDecl(hasName("push_back"))));
Finder->addMatcher(
forStmt(
hasBody(hasIgnoringBraces(
pushbackcall.bind("port_call")
))
)
, this);
This pattern of defining AST Matcher API using a lambda function finds use in other contexts. For example, sometimes we want to find and bind to an AST node if it is present, ignoring its absense if is not present.
For example, consider wishing to match struct declarations and match a copy constructor if present:
struct A
{
};
struct B
{
B(B const&);
};
We can match the AST with the anyOf() and anything() matchers.
Finder->addMatcher(
cxxRecordDecl(anyOf(
hasMethod(cxxConstructorDecl(isCopyConstructor()).bind("port_method")),
anything()
)).bind("port_record")
, this);
This can be generalized into an optional() matcher:
auto optional = [](auto const& Matcher)
{
return anyOf(
Matcher,
anything()
);
};
The anything() matcher matches, well, anything. It can also match nothing because of the fact that a matcher written inside another matcher matches itself.
That is, matchers such as
functionDecl(decl()) functionDecl(namedDecl()) functionDecl(functionDecl())
match ‘trivially’.
If a functionDecl() in fact binds to a method, then the derived type can be used in the matcher:
functionDecl(cxxMethodDecl())
The optional matcher can be used as expected:
Finder->addMatcher(
cxxRecordDecl(
optional(
hasMethod(cxxConstructorDecl(isCopyConstructor()).bind("port_method"))
)
).bind("port_record")
, this);
Yet another problem writers of clang-tidy checks will find is that AST nodes CallExpr and CXXConstructExpr do not share a common base representing the ability to take expressions as arguments. This means that separate matchers are required for calls and constructions.
Again, we can solve this problem generically by creating a composition function:
auto callOrConstruct = [](auto const& Matcher)
{
return expr(anyOf(
callExpr(Matcher),
cxxConstructExpr(Matcher)
));
};
which reads as ‘an Expression which is any of a call expression or a construct expression’.
It can be used in place of either in matcher expressions:
Finder->addMatcher(
callOrConstruct(
hasArgument(0, integerLiteral().bind("port_literal"))
)
, this);
Creating composition functions like this is a very convenient way to simplify and create maintainable matchers in your clang-tidy checks. A recently published RFC on the topic of making clang-tidy checks easier to write proposes some other conveniences which can be implemented in this manner.
Steveire's Blog 