This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Use [[clang::suppress]] with cppcoreguidelines-pro-type-reinterpret-cast
Needs ReviewPublic

Authored by mgehre on Sep 23 2016, 2:54 PM.

Details

Summary

This is a proof-of-concept how the [[clang::suppress(tags,...)]] attribute can
work with suppressing clang-tidy warnings.

The list of tags that can be used to suppress a specific warnings comes
from [1]. It is the group that the cppcoreguidelines check belongs to
("type"), the name of the check there ("type.1") and the clang-tidy
name ("cppcoreguidelines-pro-type-reinterpret-cast").

I envision to put this into all cppcoreguidelines checks. Alternatively,
this could go into clang-tidy core, to have this automatically for all
checks.

I'm looking forward to your comments!

Depends on: D24886

[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#inforce-enforcement

Diff Detail

Event Timeline

mgehre updated this revision to Diff 72363.Sep 23 2016, 2:54 PM
mgehre retitled this revision from to [clang-tidy] Use [[clang::suppress]] with cppcoreguidelines-pro-type-reinterpret-cast.
mgehre updated this object.
mgehre added reviewers: alexfh, aaron.ballman.
mgehre added a subscriber: cfe-commits.
mgehre updated this revision to Diff 72365.Sep 23 2016, 2:57 PM

Minor fix

aaron.ballman added inline comments.Sep 26 2016, 8:59 AM
clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
25

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);

clang-tidy/cppcoreguidelines/Suppression.h
59

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?

mgehre added inline comments.Sep 28 2016, 11:23 AM
clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
25

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

  1. 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)

clang-tidy/cppcoreguidelines/Suppression.h
59

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.

aaron.ballman added inline comments.Oct 11 2016, 10:24 AM
clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
25

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?

clang-tidy/cppcoreguidelines/Suppression.h
59

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.

malcolm.parsons added inline comments.
clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
25

clang-tidy reports how many warnings were suppressed by NOLINT comments.
I'd expect the number of warnings suppressed by [[clang::suppress]] to be included in the count.
Handling suppressions in the matchers or visitors would prevent this.

aaron.ballman added inline comments.Oct 11 2016, 12:20 PM
clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
25

As would handling the suppression transparently within the diagnostic engine itself.

mgehre added inline comments.Oct 20 2016, 10:56 AM
clang-tidy/cppcoreguidelines/ProTypeReinterpretCastCheck.cpp
25

If there is a way to turn a SourceLocation into a ASTNode, diag() could handle this transparently (do you know how?). I would still add an overload of diag that takes an AST node as a performance optimization, because I imagine that going from SourceLocation to ASTNode would be a costly operation.
I can prototype that approach, if you like.

clang-tidy/cppcoreguidelines/Suppression.h
59

Decl::getAttrs() will assert if called on a Decl where hasAttrs() is false, see
http://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00741

aaron.ballman added inline comments.Oct 31 2016, 12:33 PM
clang-tidy/cppcoreguidelines/Suppression.h
59

Ugh, that is a problem, but not one you should have to handle as part of this patch. I'll put it on my list of things to look into, thank you for being patient with me! :-)

bam added a subscriber: bam.Jan 4 2023, 2:20 AM

I'm sorry, could we bring it to the finish line?
It's a pity the standard C++ Core Guidelines rule suppression syntax is still not supported, as Clang-tidy is one of the main tools supporting the Guidelines..

Happy new year to all!

Herald added a project: Restricted Project. · View Herald Transcript
In D24888#4025382, @bam wrote:

I'm sorry, could we bring it to the finish line?
It's a pity the standard C++ Core Guidelines rule suppression syntax is still not supported, as Clang-tidy is one of the main tools supporting the Guidelines..

Happy new year to all!

Hi @bam, this is currently not on my priority list. Feel free to take over the PR!

bam added a comment.Jan 24 2023, 4:07 AM

I'm sorry but I'm not familiar with the codebase, so I can't help, unfortunately.