On 9/10/25 4:59 PM, David Malcolm wrote:
GCC has long supported the ability to selectively ignore warnings using "#pragma GCC diagnostic ignored"; see: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#index-pragma_002c-diagnosticThe SARIF standard supports capturing suppression information about diagnostics: the "result" objects within a "run" object can optionally all have a "suppressions" property, which, when non-empty marks a result as being suppressed, and can contain information on where the suppression occurred, and optionally contain a user-supplied "justification" string (see SARIF 2.1.0: §3.27.23 and §3.35). This patch: (a) extends "#pragma GCC diagnostic ignored" to allow the user to provide an optional justification string. (b) adds a new option "experimental-capture-suppressed-warnings" to SARIF and HTML sinks, which if "yes" triggers capturing GCC warnings suppressed via a pragma, along with any justification string. For SARIF sinks they are captured as described above. For HTML sinks they are captured at the end of the page and marked as suppressed. Text sinks always discard suppressed warnings. (c) adds machinery for this to the diagnostics subsystem. Previously, a diagnostic was either "enabled" or "disabled". If a warning is disabled, the client code is meant to stop sending follow-up notes, with code like this: if (warning_at (loc, OPT_Wsomething, "msg")) inform (other_loc, "more info"); The return value from warning_at etc is still a boolean, but internally the patch introduces a tristate called "enum acceptance", where a diagnostic is one of: (i) enabled and accepted for further processing (ii) disabled, yet still accepted for further processing, as at least one sink is capturing suppressed diagnostics (iii) disabled, and immediately rejected, as no sinks are capturing suppressed diagnostics Text sinks don't capture suppressed diagnostics, so the default case of just having a text sink has (i) and (iii) and looks a lot like the old enabled vs disabled distinction. The above is mostly handled by the diagnostics subsystem, but there are some awkward cases where the existing code suppresses false positives by also considering pragmas in effect at other locations beyond that of the diagnostic, such as at the location of a fndecl. The patch adds a new mechanism for handling this; see "extra_suppression" within option-classifier.h (d) adds test coverage for the above (e) updates sarif-replay so that it skips results that have a non-empty "suppressions" array Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. The patch isn't fully baked yet; remaining work and questions: Issue: Is the syntax for adding a justification to the pragma correct? My initial attempt looked like this: #pragma GCC diagnostic ignored "-Wunused-function" "This is a test justification" but this doesn't work as the two strings get concatted into this: #pragma GCC diagnostic ignored "-Wunused-functionThis is a test justification" So I went with this syntax: #pragma GCC diagnostic ignored "-Wunused-function" justification "This is a test justification" which works (but is perhaps too verbose?)
Maybe a colon between the strings?
Issue: what to do about warning-control.cc? There are a few places where !warning_enabled_at (some location, some opt) was being used as part of some conditional to guard: suppress_warning (some tree, the opt); which is implemented in gcc/warning-control.cc
I expect that pattern could also be converted to use extra_suppression, it seems to be another way of considering pragmas at multiple locations.
Do we also want to copy the suppression information (if any) from the 1st location to the tree's location? Martin Sebor wrote this code, and I don't think he's around anymore. Does it matter if we add fields to class nowarn_spec_t to capture such "effective suppression info"? For now I've marked these in the patch with "FIXME". Issue: do we want to capture other kinds of suppressed warnings? There are various other ways in which a warning can be suppressed; see context.cc's context::get_diagnostic_acceptance in the patch. For example, the logic for rejecting warnings when the location is in a system header. Currently the patch only captures suppression information for the pragma "ignored" case (and it's not clear how to me how to represent other kinds of suppression in SARIF).
I think it would make sense to handle system header suppression the same as #pragma suppression (with the justification "system header").
Issue: the HTML presentation of suppressed diagnostics The HTML output is a placeholder for now, and could use some work. Thoughts? Dave
