[PATCH] D59802: [clang-tidy] Add new checker: llvm-prefer-isa-or-dyn-cast-in-conditionals

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 4 04:59:19 PDT 2019


aaron.ballman added inline comments.


================
Comment at: clang-tools-extra/clang-tidy/llvm/AvoidCastInConditionalCheck.cpp:18
+
+AST_MATCHER(Expr, isMacroID) { return Node.getExprLoc().isMacroID(); }
+} // namespace ast_matchers
----------------
hintonda wrote:
> aaron.ballman wrote:
> > hintonda wrote:
> > > @aaron.ballman:  This matcher seems genuinely useful.  What do you think about moving it to ASTMatchers.h? 
> > I think that adding something like this might be a good idea. We don't have any notion of source locations in the AST matching syntax currently, and I'm not certain whether that's a good thing or not here. I'm mildly uncomfortable that this matcher operates on an `Expr` but then internally uses a source location from that expression and I wonder if we would rather introduce source location matching. For instance, what if the user cares about the difference between `getExprLoc()` and `getBeginLoc()` for some reason?
> Well, you can attach it to whatever you want, so I'm not sure that's a problem.  Alternatively, you have to check each location yourself.  In my case, that was multiple places, so putting it in the matcher cleaned up the code.
> 
> I need to verify it, but it seems that it triggered when any macros were in the range, but I need to look closer into that to understand the behavior.   I'll check it out and get back to you.
> Well, you can attach it to whatever you want, so I'm not sure that's a problem. 

How does a caller of this AST matcher indicate that they want it to match on `Node.getBeingLoc().isMacroID()` instead of what's written now? If the answer is "they write a different matcher", then that's what I think could be a problem. There's a lot of ways to get a source location (and a lot of different kinds of source locations), and I think matching on those can be very useful functionality. So I think the idea of the matcher is good, I'm just not certain whether we want it to look like `AST_MATCHER(Expr, isMacroID);` or `AST_MATCHER(SourceLocation, isMacroID);` or something else.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59802/new/

https://reviews.llvm.org/D59802





More information about the cfe-commits mailing list