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
mapping.
- Result = DiagnosticIDs::Warning;
+ // Ensure that -Wsystem-headers doesn't introduce errors due to
mapping.
+ 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.
Alp.
Maybe there's another, better, option.
Thoughts?
On Sun Dec 29 2013 at 7:01:45 AM, Alp Toker <[email protected]
<mailto:[email protected]>> 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
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
