[clang] [clang-tools-extra] [llvm] [clang] Introduce diagnostics suppression mappings (PR #112517)
kadir çetinkaya via cfe-commits
cfe-commits at lists.llvm.org
Tue Oct 29 06:58:33 PDT 2024
================
@@ -575,25 +575,42 @@ DiagnosticIDs::getDiagnosticSeverity(unsigned DiagID, SourceLocation Loc,
DiagID != diag::fatal_too_many_errors && Diag.FatalsAsError)
Result = diag::Severity::Error;
+ // Rest of the mappings are only applicable for diagnostics associated with a
+ // SourceLocation, bail out early for others.
+ if (!Diag.hasSourceManager())
+ return Result;
+
+ const auto &SM = Diag.getSourceManager();
// Custom diagnostics always are emitted in system headers.
bool ShowInSystemHeader =
!GetDiagInfo(DiagID) || GetDiagInfo(DiagID)->WarnShowInSystemHeader;
// If we are in a system header, we ignore it. We look at the diagnostic class
// because we also want to ignore extensions and warnings in -Werror and
// -pedantic-errors modes, which *map* warnings/extensions to errors.
- if (State->SuppressSystemWarnings && !ShowInSystemHeader && Loc.isValid() &&
- Diag.getSourceManager().isInSystemHeader(
- Diag.getSourceManager().getExpansionLoc(Loc)))
+ if (State->SuppressSystemWarnings && !ShowInSystemHeader &&
+ SM.isInSystemHeader(SM.getExpansionLoc(Loc)))
return diag::Severity::Ignored;
// We also ignore warnings due to system macros
bool ShowInSystemMacro =
!GetDiagInfo(DiagID) || GetDiagInfo(DiagID)->WarnShowInSystemMacro;
- if (State->SuppressSystemWarnings && !ShowInSystemMacro && Loc.isValid() &&
- Diag.getSourceManager().isInSystemMacro(Loc))
+ if (State->SuppressSystemWarnings && !ShowInSystemMacro &&
+ SM.isInSystemMacro(Loc))
return diag::Severity::Ignored;
+ // Apply suppression mappings if severity wasn't explicitly mapped with a
+ // clang-diagnostics pragma to ensure pragmas always take precedence over
+ // mappings.
+ // We also use presumed locations here to improve reproducibility for
+ // preprocessed inputs.
+ if (!Mapping.isPragma()) {
+ if (auto PLoc = SM.getPresumedLoc(Loc);
----------------
kadircet wrote:
i think it's pretty LLVM-stylistic to omit type when the initializer has enough information about the type (e.g. getXXX methods usually return something of type XXX), so I don't think it'll be more consistent with rest of clang code, but if you feel strongly about it happy to do that.
https://github.com/llvm/llvm-project/pull/112517
More information about the cfe-commits
mailing list