Make isNoThrow and hasDynamicExceptionSpec polymorphic so they can be used with both functionDecl and functionPrototype matchers.
Details
Diff Detail
Event Timeline
Sorry for the delayed response, this review got lost in my inbox!
This change will break existing out-of-tree users and would be a regression. Instead, the matcher should become a polymorphic matcher that accepts a FunctionDecl as well as a FunctionType. Check out the matcher for isConstexpr() to see how to create a polymorphic matcher. Note that you may need to use a trick like the one used in hasAnySubstatement() to handle the differences between getting the exception spec from a FunctionDecl and a FunctionType from the same matcher.
Also, can you update isNoThrow() at the same time? It has the similar behavior of currently working only on a FunctionDecl and not a FunctionType.
Finally, I'm wondering whether we want this to work on a FunctionType or a FunctionProtoType. Only functions with prototypes can have an exception specification, so putting the functionality on FunctionProtoType keeps it closer to the AST representation. However, this also may make it slightly more awkward to use in practice. Thoughts?
This marcher was recently added, and has never been in a release. Specifically, it was added by me in support of a checker that has now been abandoned in lieu of a better approach -- the new approach requires this change -- so I doubt it would break anything.
That said, I will look into polymorphic matchers if that is the preferred solution.
That's good to know, thanks!
That said, I will look into polymorphic matchers if that is the preferred solution.
Thank you -- I think that is still the right approach to take. We try to keep the matchers as close to the AST representation as possible, and this one (plus isNoThrow()) slipped through the cracks (in a useful way).
Update narrowing matchers, isNoThrow and hasDynamicExceptionSpec, to
work with both functionDecl and functionProtoType matchers. Update
tests and regenerate documentation.
Since FunctionDecl and FunctionProtoType are not polymorphically
related, an overloaded helper function, getFunctionProtoType(), was
added that takes either a FunctionDecl node or FunctionProtoType node
and returns a FunctionProtoType pointer. This is based on the
getUnderlyingType() implementation.
Since the type isn't explicitly spelled out in the initialization, probably should use const FunctionProtoType * instead of const auto *.