[PATCH] Let "-w" ignore all warnings

Richard Smith richard at metafoo.co.uk
Wed Mar 20 14:09:33 PDT 2013


On Tue, Mar 19, 2013 at 9:50 AM, Jordan Rose <jordan_rose at apple.com> wrote:

>
>   I think my point was that a diagnostic that is DefaultError is not a
> "warning" but an "error that can be turned off". Most are DefaultErrors
> because the code is invalid: even if the compiler can do something with it,
> it's probably still a bad idea (such as delegating constructor cycles or
> returning something in a void method). I wouldn't want those to go away
> when I add -w. But I may be in the minority here.
>

I think this depends to a large extent on what you think '-w' is for. I
agree that it's surprising for it to (in effect) turn on some arbitrary
subset of our language extensions, and to allow code which we know is
obviously broken -- your arguments are exactly the ones I brought up in the
past when Chandler argued for -w behaving as Daniel is now suggesting.

Chandler's counterargument (and I apologize if I've mischaracterised his
view here) was that the purpose of '-w' is to tell the compiler "I have a
blob of code which I have zero interest in fixing or maintaining, and I
just want you to parse it if you possibly can". From that perspective,
ignoring all warnings makes perfect sense (as, in fact, does ignoring all
errors with fixits). And such functionality is clearly useful both for
tooling and for dealing with legacy, perhaps third-party, code.

So I think we should have *a* mode which does the "ignore all warnings"
thing, and maybe even ignores some "recoverable" errors. I don't know if -w
should be that flag, but if it's not, what should -w mean, and who would be
its intended audience? We could continue to support -w -pedantic-errors as
an "only diagnose non-conforming code" mode.


>   FWIW, I'd be perfectly happy to say that -Wstatic-float-init should be
> an ExtWarn instead of a DefaultError, or that it's only a DefaultError in
> C++11 mode where there's an alternative.
>

The latter is exactly how it already behaves -- this is to match the
corresponding GCC extension, which the GCC folks disable in C++11 mode.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130320/f27056e4/attachment.html>


More information about the cfe-commits mailing list