This is an archive of the discontinued LLVM Phabricator instance.

[clang] Introduce support for disabling warnings in system macros
ClosedPublic

Authored by carlosgalvezp on Jan 7 2022, 11:06 AM.

Details

Summary

Often we run into situations where we want to ignore
warnings from system headers, but Clang will still
give warnings about the contents of a macro defined
in a system header used in user-code.

Introduce a ShowInSystemMacro option to be able to
specify which warnings we do want to keep raising
warnings for. The current behavior is kept in this patch
(i.e. warnings from system macros are enabled by default).
The decision as to whether this should be an opt-in or opt-out
feature can be made in a separate patch.

To put the feature to test, replace duplicated code for
Wshadow and Wold-style-cast with the SuppressInSystemMacro tag.
Also disable the warning for C++20 designators, fixing #52944.

Diff Detail

Event Timeline

carlosgalvezp requested review of this revision.Jan 7 2022, 11:06 AM
carlosgalvezp created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 7 2022, 11:06 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rsmith added inline comments.Jan 7 2022, 11:15 AM
clang/lib/Sema/SemaExpr.cpp
7161

I think we should be checking Diags.getSuppressSystemWarnings() before considering whether we're in a system header. (Eg, if we're building libc++ and it enables warnings even in system headers, we want to warn if it uses non-C++ designator syntax.)

Given that this is something that we will presumably want to do for a bunch of diagnostics, not just this one, I think we should extend the current ShowInSystemHeader / SuppressInSystemHeader markings in our diagnostics .td files to also have a SuppressInSystemMacro level, and handle this centrally with the other "suppress warnings in system headers" logic, rather than special-casing this here.

carlosgalvezp added inline comments.Jan 7 2022, 11:26 AM
clang/lib/Sema/SemaExpr.cpp
7161

Thanks for the quick feedback!

Fully agree, thanks for the pointers. I tried to apply a similar fix here but got quite a few tests failing so I thought maybe the intention was to apply this on a case-by-case basis.

I'll see what I can do with the .td files, thanks!

What unit test file should I use to verify my changes?

carlosgalvezp retitled this revision from [clang][Sema] Disable -Wc++20-designator in system macros to [clang][Sema] Introduce support for disabling warnings in system macros.
carlosgalvezp edited the summary of this revision. (Show Details)

Introduce centralized framework for suppressing warnings,
to avoid code duplication for each check.

Clean up the code for -Wshadow and -Wold-style-cast, which
was introduced together with their unit tests in
https://github.com/llvm/llvm-project/commit/15ab37321cbdb8c38e30cf8bd59bad52f4497580

Updated according to your feedback, let me know what you think! I've run ninja check-clang successfully, let me know if there's any other test I should run. Personally I think this ShowInSystemMacro should be OFF by default (to be consistent with ShowInSystemHeader), but I think this can be done in a separate patch if wanted. Otherwise there's ~15 tests to fix.

Keep 80 char limit in .td file.

carlosgalvezp retitled this revision from [clang][Sema] Introduce support for disabling warnings in system macros to [clang] Introduce support for disabling warnings in system macros.

Update DIAG in clang-tools-extra/Diagnostics

Herald added a project: Restricted Project. · View Herald TranscriptJan 8 2022, 8:29 AM
Herald added a subscriber: kadircet. · View Herald Transcript

I'll just note here that doing this globally is likely to have unexpected results... consider, for example:

#include <math.h>
void f() { long x = M_PI; }

Currently, the implicit conversion warning points into math.h.

That said, I don't see any problem with the current implementation.

I'll just note here that doing this globally is likely to have unexpected results... consider, for example:

#include <math.h>
void f() { long x = M_PI; }

Currently, the implicit conversion warning points into math.h.

That said, I don't see any problem with the current implementation.

Yes, at first I set the default to "disable globally" and got around ~15 failed tests similar to your example. I don't have a good enough picture of all the existing warnings to determine what's preferred here, but I think we can take it in a separate patch. I get a much better insight now about why this has not been tackled before and why some warnings from system macros are needed!

I can also mention that we have recently merged a patch to disable clang-tidy warnings from system macros:
https://reviews.llvm.org/D116378

rsmith accepted this revision.Jan 11 2022, 7:04 PM

Thanks, this looks nice.

I think we'll need to think carefully before changing the default here. It seems like the choice here would depend on what token the location of the diagnostic points to -- if we know that the token is directly responsible for the warning, then suppressing the warning makes sense, but if some of the code responsible for the warning is outside the system header (even though the token at the diagnostic location is not), then we probably still want to warn. I don't think we provide enough information to the diagnostic system to decide this on a global basis. In any case, this change should make it really easy to give the new behavior to more diagnostics.

This revision is now accepted and ready to land.Jan 11 2022, 7:04 PM

Thanks, this looks nice.

I think we'll need to think carefully before changing the default here. It seems like the choice here would depend on what token the location of the diagnostic points to -- if we know that the token is directly responsible for the warning, then suppressing the warning makes sense, but if some of the code responsible for the warning is outside the system header (even though the token at the diagnostic location is not), then we probably still want to warn. I don't think we provide enough information to the diagnostic system to decide this on a global basis. In any case, this change should make it really easy to give the new behavior to more diagnostics.

Thanks a lot for the quick review! I agree that we should analyze it carefully if we want to change default behavior. For now this solves my immediate needs so I'll leave it at that :)