[PATCH] D24888: [clang-tidy] Use [[clang::suppress]] with cppcoreguidelines-pro-type-reinterpret-cast

[Aaron Ballman via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp:25
 
-  Finder->addMatcher(cxxReinterpretCastExpr().bind("cast"), this);
+  std::vector<StringRef> Rules{"type", "type.1", "cppcoreguidelines-pro-type-reinterpret-cast"};
+  Finder->addMatcher(cxxReinterpretCastExpr(unless(isSuppressed(Rules))).bind("cast"), this);
----------------
mgehre wrote:
> aaron.ballman wrote:
> > Hmm, it seems like this is boilerplate we are going to want for every rule, and that it's pretty easy to not get this right (for instance, if you change the way the check is spelled, you have to remember to update this as well). Could this actually be handled more transparently, by gathering this information when the check is registered and exposing it to the check?
> > 
> > The checks would still need to use `unless(isSuppressed(Rules))` in some form, but I am thinking that it would be more convenient if we could do: `Finder->addMatcher(cxxReinterpretCastExpr(unlessSuppressed(*this)).bind("cast"), this);`
> I see multiple ways on how to integrate that into clang-tidy:
> 1) Add something like you proposed to each matcher of each check
> 2) Change (or add overload of)
> ```
>  DiagnosticBuilder diag(SourceLocation Loc, StringRef Description,
>                          DiagnosticIDs::Level Level = DiagnosticIDs::Warning);
> ```
> to add a AST node as parameter and make the SourceLocation optional. Most checks anyhow
> call this like diag(E->getLoc(), "...."), and then they would do diag(E, "...").
> Diag then would check from the that AST node upwards to see if it finds a matching [[suppress]] attribute
> 
> 3) Change the RecursiveASTVistor that drives the AST Matches to prune certain matchers from the list of to-be-evaluated matchers
> for all AST subtrees that are below a certain [[suppress]] attribute. (This is based on how I image that the AST matchers work)
Ideally, I would like to see this attribute used to suppress Clang diagnostics as well, however. So while I think Option 2 is better suited to that future direction, it's still not ideal because all instances of diag() need to be updated to take advantage. Options 1 and 3 are basically limited to clang-tidy use.

I wonder if there's a way to modify the diagnostic builder to transparently handle this without requiring modifying all of the call sites?


================
Comment at: clang-tidy/cppcoreguidelines/Suppression.h:59
+             anyOf(hasAncestor(attributedStmt(hasSuppressAttr(Rules))),
+                   hasAncestor(decl(hasAttrs(), hasSuppressAttr(Rules)))))
+      .matches(Node, Finder, Builder);
----------------
mgehre wrote:
> aaron.ballman wrote:
> > Why is the check for `hasAttrs` required?
> > 
> > Also, this use of `hasAncestor()` makes this expensive to use, and that expense may be hidden from the caller. Is there a way to structure this so that we don't need to walk the entire ancestor tree?
> hasAttr() is needed here, because inside of hasSuppressAttr(), we call getAttrs() which would assert if hasAttr() is false.
> I cannot push hasAttr() into hasSuppressAttr(), because hasSuppressAttr() is a template getting either Decl or AttributedStmt,
> and AttributedStmt does not have an hasAttr() method.
I believe that `getSpecificAttr` should be resilient to no attributes being present (since it also has to handle the case there are no attributes of the specific type, so no attributes at all is simply a degenerate case), and so the check for `hasAttrs()` should be redundant.


https://reviews.llvm.org/D24888