This is an archive of the discontinued LLVM Phabricator instance.

[ASTMatchers] Add matchers for `CXXDeleteExpr`
Needs ReviewPublic

Authored by njames93 on Mar 1 2021, 5:58 AM.

Details

Summary

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.

Diff Detail

Event Timeline

njames93 requested review of this revision.Mar 1 2021, 5:58 AM
njames93 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2021, 5:58 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman added inline comments.Mar 1 2021, 7:04 AM
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?

njames93 added inline comments.Mar 1 2021, 7:50 AM
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.
You can put any matcher in, that may not make sense or ever be capable of actually matching but it will happily compile without emitting any warning. using deletes forces some type checking on the argument you provide.
The explicit names are also much better for documentation and API discovery.
When running in clang query with completions this is what appears at the top of the list

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 [].
Maybe there is merit to check traversal kind before assuming tho.

clang/lib/ASTMatchers/Dynamic/Registry.cpp
269

Accident. Will re add.

aaron.ballman added inline comments.Mar 1 2021, 8:09 AM
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.

njames93 added inline comments.Mar 1 2021, 9:18 AM
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.