Required for D22220
Details
Diff Detail
Event Timeline
Retracting from review for the moment. Tests fail to compile (embarrasingly enough, I ran the wrong test suite -- apologies).
Updated test and documentation for hasUnderlyingDecl() to use using declarations instead of typedefs. (I made the mistaken assumption that getUnderlyingDecl() would also work on a typdef and didn't catch the mistake because I ran the wrong tests.)
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
2808 | I find the name of this matcher a little bit confusing. The documentation doesn't describe what the matcher does (can you please clarify the docs?). The implementation suggests that this is looking to see if the given decl exists in the overload expression set, which makes me wonder why this isn't implemented on the hasDeclaration() traversal matcher rather than adding a new matcher name? |
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
2808 | I don't like hasDeclaration, as that's so far used when there is exactly one. Something like hasAnyDeclaration might also fit, but I think canReferToDecl makes it clear that there is not yet a specific decl, but a couple of candidates we'll want to select from. |
I've rebased the patch to a newer head revision, which seems to confuse Phabricator when diffing against earlier versions of the patch. Apologies. I assume this means I should avoid doing this (rebasing to a newer revision)?
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
2440 | I was trying to match the style of the next matcher below -- or do you think I should establish a precedent / preference for emitting the superfluous parentheses? | |
2808 |
I've rephrased the description of the matcher -- is it clearer now?
As klimek notes, the difference is that hasDeclaration() is currently used only for nodes that have exactly one associated declaration. My proposal would be to stay with canReferToDecl -- thoughts? |
No, rebasing is totally fine. But if some files changed in the meantime, comparing with older revisions will contain unrelated changes, that's expected, I think.
include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
2808 | canReferToDecl doesn't make it any more clear that there could be multiple candidates, and I find its usage to read really strangely. However, it is a good point about hasDeclaration usage being singular currently. My preference is for hasAnyDeclaration, and the precedence is hasAnyName, hasAnyConstructorInitializer, hasAnyArgument, etc. The documentation does read better now, thank you! |
Assuming others are fine with hasAnyDeclaration() vs canReferToDecl(), LGTM! If others feel strongly about canReferToDecl() instead, it still LGTM.
nit: Parentheses are superfluous here.