TemplateSpecializationType doesn't quite have getDecl(). Need to go
through TemplateName to get a TemplateDecl.
Added test cases for the hasDeclaration() overload for
TemplateSpecializationType. Also introduced the type matcher
templateSpecializationType() used by the new hasDeclaration() test case.
Updated LibASTMatchersReference.
Reviewers: klimek
llvm-svn: 176025
Re-introducing r175532. The has_getDecl metafunction didn't compile with
Visual Studio. This revision uses approaches has_getDecl from a
different angle that isn't a problem for Visual Studio.
Added dedicated tests for the metafunction.
Reviewers: klimek
llvm-svn: 176024
Re-introducing r175532. The has_getDecl metafunction didn't compile with Visual
Studio. This revision approaches has_getDecl from a different angle that isn't
a problem for Visual Studio.
Added dedicated tests for the metafunction.
Reviewers: klimek
llvm-svn: 176019
Using a new metafunction for detecting the presence of the member
'getDecl' in a type T, added support to hasDeclaration for any such type
T. This allows hasDecl() to be replaced and enables several other
subclasses of clang::Type to use hasDeclaration.
Updated unittests and LibASTMatchersReference.html.
Reviewers: klimek
llvm-svn: 175532
This is a powerful tool when doing iterative refined matches,
where another match is started inside the match callback of the first
one; this allows for example to find out whether the node was in
the condition or body of its parent if-statement.
llvm-svn: 174605
A very common use case is to search for the first occurrence of
a certain node that is a descendant of another node. In that
case, selectFirst significantly simplifies the code at the client side.
llvm-svn: 174499
We found that findAll has been implemented incorrectly multiple times
by various people using the matchers. To prevent further wasted
development effort, it makes sense to add it as convenience matcher
implemented as eachOf(m, forEachDescendant(m)).
This patch also updates the docs with the new matchers.
llvm-svn: 174320
eachOf gives closure on the forEach and forEachDescendant matchers.
Before, it was impossible to implement a findAll matcher, as matching
the node or any of its descendants was not expressible (since anyOf
only triggers the first match).
llvm-svn: 174315
First, this implements a match() method on MatchFinder; this allows us
to get rid of the findAll implementation, as findAll is really a special
case of recursive matchers on match.
Instead of findAll, provide a convenience function match() that lets
users iterate easily over the results instead of needing to implement
callbacks.
llvm-svn: 174172
The problem is that a partial match of an (explicit or implicit) allOf matcher
binds results, i.e.
recordDecl(decl().bind("x"), hasName("A"))
can very well bind a record that is not named "A". With this fix, the common
cases of stumbling over this bug are fixed by the BoundNodesMap overwriting the
results of a partial match. An error can still be created with a weird
combination of anyOf and allOf (see inactive test). We need to decide whether
this is worth fixing, as the fix will have performance impact.
Review: http://llvm-reviews.chandlerc.com/D124
llvm-svn: 168177
When recursively visiting the generated matches, the aggregated bindings need
to be copied during the recursion. Otherwise, we they might not be properly
overwritten (which is shown by the test), or there might be bound nodes present
that were bound on a different matching branch.
Review: http://llvm-reviews.chandlerc.com/D112
llvm-svn: 167695
Often users of the ASTMatchers want to add tasks that are done once per
translation unit, for example, cleaning up caches. Combined with the
interception point for the end of source file one can add to the factory
creation, this covers the cases we've seen users need.
llvm-svn: 167271
This implements has(), hasDescendant(), forEach() and
forEachDescendant() for NestedNameSpecifier and NestedNameSpecifierLoc
matchers.
Review: http://llvm-reviews.chandlerc.com/D86
llvm-svn: 167017
Without this patch, the isDerivedFrom matcher asserts in the
"assert(ClassDecl != NULL);" in the new test, as a
DependentTemplateSpecilizationType is not a sub-type of
TemplateSpecializationType and also does not offer getAsCXXRecordDecl().
I am not sure why this did not cause problems before. It is now (after
the changed implementation of isDerivedFrom) easier to write a matcher
that actually gets into this branch of the code.
llvm-svn: 164127
Having Expr-subclass-matchers being VariadicDynCast-Expr-matchers does
not provide additional type safety and just makes using them harder. In
the clang AST, expressions are always statements and an expression
matcher can be used anywhere, a statement matcher is expected. Any given
matcher definition still has at least one noun.
llvm-svn: 164121
There are two evils we can choose from:
- Name overlap between isA-matcher and llvm::isa<>()
- Bad name for what the isA-matcher currently does
After some discussion we have agreed to go with the latter evil.
Review: http://llvm-reviews.chandlerc.com/D40
llvm-svn: 163740
class itself. This caused some confusion (intuitively, a class is not
derived from itself) and makes it hard to write certain matchers, e.g.
"match and bind any pair of base and subclass".
The original behavior can be achieved with a new isA-matcher. Similar
to all other matchers, this matcher has the same behavior and name as
the corresponding AST-entity - in this case the isa<>() function.
llvm-svn: 163385
Implements the hasAncestor matcher. This builds
on the previous patch that introduced DynTypedNode to build up
a parent map for an additional degree of freedom in the AST traversal.
The map is only built once we hit an hasAncestor matcher, in order
to not slow down matching for cases where this is not needed.
We could implement some speed-ups for special cases, like building up
the parent map as we go and only building up the full map if we break
out of the already visited part of the tree, but that is probably
not going to be worth it, and would make the code significantly more
complex.
Major TODOs are:
- implement hasParent
- implement type traversal
- implement memoization in hasAncestor
llvm-svn: 163382
Edwin Vane