[PATCH] PR18327: -Wsystem-headers introduces build errors

Alp Toker alp at nuanti.com
Mon Jan 6 13:02:07 PST 2014

On 06/01/2014 19:27, Richard Smith wrote:
> We need to figure out what -Wsystem-headers should do in some corner 
> cases. In particular:
>  * If I -Werror= a warning, and I have -Wsystem-headers, and the 
> warning occurs in a system header, what should happen?
>  * If I use -Werror=system-headers, and a DefaultError warning (like 
> -Winvalid-constexpr) is issued in a system header, what should happen?
>  * If I use -Werror=system-headers, and a (non-promoted-to-error) 
> warning occurs in a system header, what should happen?
>  * If I use -Werror globally, and I have -Wsystem-headers enabled, and 
> a warning is produced in a system header, what should happen?
> One possible approach would be to set the apparent severity of 
> diagnostics in system headers to max(warning severity, 
> -Wsystem-headers severity). So -Wsystem-headers would allow warnings 
> (but not errors) to be produced in system headers, and 
> -Werror=system-headers would also allow errors to be produced in 
> system headers.

Getting -W[no-]error=system-headers play ball sounds like it'd need work 
given what a special case it is, with limited use cases for all that 
flexibility. My motivation here was just to make -Wsystem-headers safe 
to enable at all.

I suspect -Wsystem-headers -Werror should treat all header warnings as 
errors though. Think we have a workable solution if I update the 
proposed patch with that case?

-      // Ensure that -Wsystem-headers never introduces errors due to 
-      Result = DiagnosticIDs::Warning;
+      // Ensure that -Wsystem-headers doesn't introduce errors due to 
+      if (!Diag.WarningsAsErrors)
+        Result = DiagnosticIDs::Warning;

> Another would be your current patch (never produce errors in system 
> headers).

Just to clarify, the patch only prevents new errors being introduced by 
-Wsystem-headers that would not otherwise fire. It doesn't suppress any 
other errors that usually fire in system headers.

> Another would be to treat all warnings in system headers as if they're 
> controlled by the -Wsystem-headers flag (so -Werror=system-headers 
> would promote them all to errors, as would -Werror -Wsystem-headers).

Would that need early checks on the warning location to see if it's in 
system headers? The check is described as expensive so I've left it 
until just before emission.


> Maybe there's another, better, option.
> Thoughts?
> On Sun Dec 29 2013 at 7:01:45 AM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>     The -Wsystem-headers option was enabling warnings that got upgraded to
>     errors
>     through mappings like DefaultError. In a normal build these errors
>     are fully
>     suppressed.
>     This patch makes -Wsystem-headers consistent with ordinary
>     behaviour by
>     restoring mapped errors in system headers to warnings, ensuring
>     that the
>     option
>     can never cause build failures.
>     The test case extends existing checks added in r169689 / PR14550.
>     Alp.
>     --
>     http://www.nuanti.com
>     the browser experts

the browser experts

More information about the cfe-commits mailing list