[cfe-commits] r141053 - in /cfe/trunk: include/clang/Basic/DiagnosticDriverKinds.td lib/Driver/Tools.cpp

Bob Wilson bob.wilson at apple.com
Tue Oct 4 10:26:51 PDT 2011

On Oct 4, 2011, at 10:16 AM, David Blaikie wrote:

> On Tue, Oct 4, 2011 at 10:09 AM, Ted Kremenek <kremenek at apple.com> wrote:
> On Oct 4, 2011, at 9:27 AM, David Blaikie wrote:
>> Could/should we support -Wno-* by default anyway? I mean if we don't
>> have the warning it is certainly not on.
>> (on the other hand, as a user I wouldn't mind knowing if I'm passing
>> useless flags. Except when I'm trying to use multiple compilers and
>> turn something off in one which isn't present in the other. Minor
>> convenience to have that silently(ish) accepted on the no supporting
>> compiler)
> Hi David,
> Numerous people have requested that all warnings can be placed under a -W flag, and allow them to selectively turn them on or off.  I'll try and summarize why I think this is a critical feature.
> Oh, sorry - I think I wasn't clear. I believe I understand & agree with the motivation (& if I get a chance I'll have a go & providing some patches to group the ungrouped warnings to help get that 304 down to zero). My point was (& it's possible this is the existing behavior, I don't have access to clang right now to test) to counter Bob's point (that he wouldn't want to break users who were disabling (-Wno-blah) the warning when the warning was removed):
> Could we just silently allow users to pass -Wno-foo & if we don't have a warning called 'foo' we could just silently swallow this flag & ignore it? Since we don't support the 'foo' warning anyway, we can trivially support -Wno-foo.

I'm not a fan of that.  If you have a typo in your compile command, clang will silently eat the invalid option without giving you any feedback.  That's not good.

If we have to do anything, and hopefully it won't come up, we could temporarily leave the old warning option for a short time to give people time to remove it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111004/bf303071/attachment.html>

More information about the cfe-commits mailing list