Details
- Reviewers
aaron.ballman NoQ dcoughlin sbenza klimek - Commits
- rG9d1d0c4c5747: [ASTMatchers] Extend hasParameter and hasAnyParameter matches to handle…
rC328746: [ASTMatchers] Extend hasParameter and hasAnyParameter matches to handle…
rL328746: [ASTMatchers] Extend hasParameter and hasAnyParameter matches to handle…
Diff Detail
- Repository
- rL LLVM
Event Timeline
@aaron.ballman OK.
BTW do you know how to fix the following:
clang-query> match anyOf( objcMethodDecl(), functionDecl() ) Input value has unresolved overloaded type: Matcher<Decl>&Matcher<Decl>
The underlying problem is that the only base class they have in common is Decl (though I'm not sure why is it a problem?..)
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
3486 ↗ | (On Diff #139239) | This statement isn't quite correct -- it matches the objcMethodDecl() with hasAnyArgument(...) matching int y. However, why is this calling hasAnyArgument instead of hasParameter? |
3543 ↗ | (On Diff #139204) | Should add a code example for hasAnyParameter. |
unittests/ASTMatchers/ASTMatchersTraversalTest.cpp | ||
572 ↗ | (On Diff #139239) | You should also have a test for hasParameter(). |
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
3496 ↗ | (On Diff #139341) | Yes, this is ugly, and I do plan to eventually introduce a common superclass, so we could enforce same name for same operations. |
3469 ↗ | (On Diff #139204) | Decided to revert this block, getting it right is a bit tricky, and I do not need that right now. |
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
3496 ↗ | (On Diff #139341) | Both classes have a parameters() member function that returns an ArrayRef<ParmVarDecl *>, so I think this could be factored to use that function in both cases and have common count checking. |
lib/Analysis/BodyFarm.cpp | ||
317 ↗ | (On Diff #139343) | This change looks unrelated to the patch. |
LGTM with a minor doc nit.
docs/LibASTMatchersReference.html | ||
---|---|---|
5336–5337 ↗ | (On Diff #139367) | The doxygen use here seems to be causing fits for the generated docs. You can drop its use in these cases. |
@aaron.ballman turns out larger changes for dynamic tests were required, could you take a brief look?
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) | the problem here is that it's not a dyn_typed_matcher anymore. |
336 ↗ | (On Diff #139383) | seems that the order is not actually fixed |
Adding some folks to review the dynamic matcher bits.
include/clang/StaticAnalyzer/Core/PathSensitive/WorkList.h | ||
---|---|---|
90 ↗ | (On Diff #139383) | This change looks unrelated (but would be fine to commit on its own without waiting for review). |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
189 ↗ | (On Diff #139383) | I'm not as familiar with the dynamic matcher infrastructure as I am other parts of the matchers; can you give a bit more background on what's happening here? |
include/clang/StaticAnalyzer/Core/PathSensitive/WorkList.h | ||
---|---|---|
90 ↗ | (On Diff #139383) | yeah somehow i always screw up the exact thing I am meant to sent to the diff, thanks! |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
189 ↗ | (On Diff #139383) | @aaron.ballman OK. |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) | Hmm, so will this break behavior for clang-query users where their use of hasParameter() is now ambiguous? Or are these changes only needed because we're not really being fully dynamic in the unit tests like we are with clang-query directly? |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) | From what I have tried, hasParameter works in clang-query as before (just as hasArgument does). |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) |
@aaron.ballman clang-query> match hasParameter(0, parmVarDecl()) Input value has unresolved overloaded type: Matcher<FunctionDecl|ObjCMethodDecl> The previous behavior can easily obtained though: clang-query> match functionDecl(hasParameter(0, parmVarDecl())) Match #1: ... |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) | The lack of a reasonable common supertype for functionDecl and objcMethodDecl is very annoying. Strangely, this does not work: clang-query> match decl(hasParameter(0, parmVarlDec)) 1:2: Error building matcher decl. 1:7: Incorrect type for arg 1. (Expected = Matcher<Decl>) != (Actual = Matcher<FunctionDecl|ObjCMethodDecl>) So we have to go through the hoops: clang-query> match decl(anyOf(objcMethodDecl(hasParameter(0, parmVarDecl())), functionDecl(hasParameter(0, parmVarDecl())))) |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) | Ah, that's what I was afraid of. However, because this is a traversal matcher, I have a hard time imagining that anyone uses the matcher in this way because there would be no current node to traverse *from* in a top-level hasParameter() match. I think the behavior change will be reasonable. What do you think, @sbenza and @klimek? |
unittests/ASTMatchers/Dynamic/ParserTest.cpp | ||
---|---|---|
189 ↗ | (On Diff #139383) | I'm also sort of puzzled why the typechecker can not figure out a common superclass. Maybe just in order to be consistent with static behavior. |