This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Disable clang-tidy warnings from system macros
ClosedPublic

Authored by carlosgalvezp on Dec 29 2021, 8:40 AM.

Details

Summary

Currently, it's inconsistent that warnings are disabled if they
come from system headers, unless they come from macros.
Typically a user cannot act upon these warnings coming from
system macros, so clang-tidy should ignore them unless the
user specifically requests warnings from system headers
via the corresponding configuration.

This change broke the ProTypeVarargCheck check, because it
was checking for the usage of va_arg indirectly, expanding it
(it's a system macro) to detect the usage of __builtin_va_arg.
The check has been fixed by checking directly what the rule
is about: "do not use va_arg", by adding a PP callback that
checks if any macro with name "va_arg" is expanded. The old
AST matcher is still kept for compatibility with Windows.

Add unit test that ensures warnings from macros are disabled
when not using the -system-headers flag. Document the change
in the Release Notes.

Diff Detail

Event Timeline

carlosgalvezp created this revision.Dec 29 2021, 8:40 AM
carlosgalvezp requested review of this revision.Dec 29 2021, 8:40 AM
carlosgalvezp retitled this revision from Disable clang-tidy warnings from system macros to [clang-tidy] Disable clang-tidy warnings from system macros.Dec 31 2021, 8:13 AM
salman-javed-nz added inline comments.Jan 6 2022, 2:36 AM
clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
23–40

Should this be in another patch?

Line 722 in ClangTidyDiagnosticConsumer.cpp makes it so that clang-tidy filters warnings from system macros. This would benefit all checks.

This VaArgPPCallBack change here only benefits cppcoreguidelines-pro-type-vararg.

29–60

Formatting changed for code not directly involved in this patch. Should be moved to a separate NFC commit that you don't have to run by us.

estan added a subscriber: estan.Jan 6 2022, 4:03 AM
carlosgalvezp added inline comments.Jan 6 2022, 4:57 AM
clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
23–40

The change to ClangTidyDiagnosticConsumer.cpp broke this check, because it was checking for the use of vararg indirectly, checking for the use of __builtin_vararg, which was expanded from the system macro vararg. This patch updates the code so it checks directly what the rule is about "do not use vararg". I should perhaps have been more clear about that in the commit message :)

29–60

Yes, it's a bit unfortunate, this was an automatic change on save from my editor. Is it really worth it to revert this change though? I will need to disable this feature on my IDE, revert each line manually by adding a space, push, then re-enable the feature. Sounds like a lot of time spent on reverting a change that anyway improves the state of the code.

Revert formatting, clarify necessary changes to existing check in the commit message.

carlosgalvezp edited the summary of this revision. (Show Details)Jan 6 2022, 5:32 AM
carlosgalvezp added inline comments.
clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
23–40

Messed up names above, I meant va_arg and __builtin_va_arg.

29–60

Fixed.

aaron.ballman accepted this revision.Jan 6 2022, 11:03 AM

LGTM aside from a minor nit, thanks! This was a good catch.

clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
32–33

Rather than duplicate the diagnostic text, I think we should hoist the text into a constant string that's used in both places.

That makes it easier to fix the diagnostic (in a follow up) to properly quote va_arg and convert the grammar to singular form instead of plural (e.g, do not use 'va_arg' to define a C-style vararg function; use a variadic template instead).

This revision is now accepted and ready to land.Jan 6 2022, 11:03 AM
  • Refactor duplicated warning message into a common variable.
  • Remove double backticks change, TBH I get conflicting review comments about this and can't find any docs supporting either, so I'll just keep it consistent.
  • Move extra class to the existing anonymous namespace instead of creating a new one.

Thanks for the review! I've fixed the nit, reverted unrelated changes to backticks and moved the class to the existing anonymous namespace. Since those are NFC changes I'll push now, if you don't agree let me know and I'll revert right away :)

clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
32–33

Of course!

This revision was landed with ongoing or failed builds.Jan 6 2022, 12:28 PM
This revision was automatically updated to reflect the committed changes.

This resolves the long-standing gripe I have with clang-tidy raising warnings about GoogleTest macros expanded in my code. Good work.
Do you think we can close issues #44873, #43325, and #31587 now that we have this fix?

This resolves the long-standing gripe I have with clang-tidy raising warnings about GoogleTest macros expanded in my code. Good work.
Do you think we can close issues #44873, #43325, and #31587 now that we have this fix?

Thanks! It has been bugging me for long time as well :)

It seems to me those issues could be closed, yes.

By the way, the similar problem exists in Clang compiler. I have written in cfe-dev, Discourse and submitted an issue without any feedback so far (I understand it's been vacation). Do you think it would be beneficial to implement a similar fix there? I don't know if the fix is as straightforward as in clang-tidy or if it will have to be done on a per-check basis.

By the way, the similar problem exists in Clang compiler. I have written in cfe-dev, Discourse and submitted an issue without any feedback so far (I understand it's been vacation). Do you think it would be beneficial to implement a similar fix there? I don't know if the fix is as straightforward as in clang-tidy or if it will have to be done on a per-check basis.

Speaking as just a user of the compiler and not a contributor (I tend to stick in Clang-Tidy land), yes, a fix would be great. Especially if you're getting unactionable warnings coming from STM32 libraries - it's a platform I have to develop for too. Not sure where in Clang you would make the change. At a cursory glance, the commits in Clang/ I saw to do with stopping system header warnings from bubbling up were done in the individual warnings, not in common code. Best to check with someone who works in that area.