ymandel added a comment.
> I'm not concerned about the basic idea behind the proposed matcher, I'm only
> worried we're making AST matching more confusing by having two different ways
> of inconsistently accomplishing the same-ish thing.
Aaron, I appreciate this concern, but I would argue that this matcher isn't
making things any worse. We already have the various `ignoringImplicit`
matchers, and this new one simply parallels those, but for parents. So, it is
in some sense "completing" an existing API, which together is an alternative to
`traverse`.
We should decide our general policy on these implict matchers vs the traverse
matchers. Personally, I view `traverse` as an experimental feature that we're
still figuring out and so would prefer that it not block progress on new
matchers. But, I'm open to discussion. I can implement this one in my own
codebase in the meantime if this requires longer discussion (that is, it's not
blocking me, fwiw).
Also, I don't believe that traverse work in this case. When I change the test
to use `traverse`, it fails:
TEST(HasParentIgnoringImplicit, TraverseMatchesExplicitParents) {
std::string Input = R"cc(
float f() {
int x = 3;
int y = 3.0;
return y;
}
)cc";
// ---> Passes because there are not implicit parents.
EXPECT_TRUE(matches(
Input, integerLiteral(traverse(TK_IgnoreImplicitCastsAndParentheses,
hasParent(varDecl())))));
EXPECT_TRUE(
matches(Input,
declRefExpr(traverse(TK_IgnoreImplicitCastsAndParentheses,
hasParent(returnStmt())))));
EXPECT_TRUE(
matches(Input,
floatLiteral(traverse(TK_IgnoreImplicitCastsAndParentheses,
hasParent(varDecl())))));
}
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D88275/new/
https://reviews.llvm.org/D88275
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
