Add deletes traveral matcher which matches on the expression being delete
Extend CXXNewExpr::isArray matcher to work for CXXDeleteExpr. Currently this only matches array delete expressions as written.
Details
- Reviewers
klimek aaron.ballman steveire
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
7621 | Why add this instead of continuing to use has()? (I worry a bit that we'll want to add a verb for different subexpression matchers and it won't scale well or we won't add verbs for different subexpressions and this'll introduce a new inconsistency.) | |
clang/include/clang/ASTMatchers/ASTMatchersInternal.h | ||
163 | Do we need/want this interface to consider whether the user is matching things spelled in source or not? | |
clang/lib/ASTMatchers/Dynamic/Registry.cpp | ||
269 | Why removing this? |
clang/include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
7621 | This change is about lowering the barrier to entry. While has can be very powerful, its interface isn't newcomer friendly. clang-query> m cxxDeleteExpr( Matcher<CXXDeleteExpr> deletes(Matcher<Expr>) Matcher<CXXDeleteExpr> isArray() A similar case is made for the matchers documentation. | |
clang/include/clang/ASTMatchers/ASTMatchersInternal.h | ||
163 | From what I can see the only time isArrayFrom and isArrayFromAsWritten differentiate is if normal delete operator is used on an arrayType. However that behaviour isn't standard afaik and was only added to be consistent with gcc and edg. If that case comes up we emit a fixit to add the []. | |
clang/lib/ASTMatchers/Dynamic/Registry.cpp | ||
269 | Accident. Will re add. |
clang/include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
7621 | Thanks! I agree with your assessment about this being a more user-friendly interface. My concerns are more mundane though. IIRC, each time we add a new matcher, we slow down compilation for the entire Clang project by a nontrivial amount because of the large amount of template instantiations involved. Because of that, we usually only add matchers when we find there's a need for them (as opposed to generating matchers for everything possible). So I worry that we'll slow down compile times and increase build sizes for a relatively uncommon AST matcher that isn't strictly necessary, and that it'll be a slippery slope to do more of this. That said, I've not measured the slowdown and perhaps things have improved here. @klimek may have more context or thoughts on this. | |
clang/include/clang/ASTMatchers/ASTMatchersInternal.h | ||
163 | I think it's defensible either way, so I leave it to whatever you and @steveire think is appropriate. |
clang/include/clang/ASTMatchers/ASTMatchers.h | ||
---|---|---|
7621 | That is a good point, maybe though if we felt so inclined. We could actually split up the Matcher definitions from their declarations. It may not work as nicely with PolymorphicMatchers but given around 3/4 of the matchers aren't, It could have a positive impact on compile time. |
Why add this instead of continuing to use has()? (I worry a bit that we'll want to add a verb for different subexpression matchers and it won't scale well or we won't add verbs for different subexpressions and this'll introduce a new inconsistency.)