[cfe-commits] [PATCH] Remove -Wdisabled-macro-expansion

Abramo Bagnara abramo.bagnara at bugseng.com
Tue Oct 30 00:27:45 PDT 2012

Il 30/10/2012 05:07, Ted Kremenek ha scritto:
> On Oct 29, 2012, at 8:38 PM, Eli Friedman <eli.friedman at gmail.com
> <mailto:eli.friedman at gmail.com>> wrote:
>> I think there's a reasonable workflow for small projects which
>> involves using -Weverything and subtracting out the warnings which
>> don't make sense.
> Right.  I commented about this in my other email before I saw your response.
>>  I agree that there are limits to what we can/should
>> do with -Weverything; I'm not trying to argue for getting rid of
>> warnings because they make -Weverything too noisy.  On the other hand,
>> I think we should have a high standard for the usefulness of
>> off-by-default warnings.  And I think that there's future
>> infrastructure work we can do both to help people write higher quality
>> code.
> Agreed.  FWIW, the developers we have spoken to about -Weverything
> really like how it has been very helpful in discovering warning flags
> that are very good for their codebase.
>>>> it isn't acceptable for it to trigger warnings for usage
>>>> of headers included with the compiler, and as far as I can tell, there
>>>> isn't any way to fix the header. (See patch for a testcase that
>>>> checks we don't trigger any warnings from stdbool.h.)
>>>> I'm planning to commit this unless someone has an alternative
>>>> suggestion.
>>> Could you suppress the warning if the spelling location for the token
>>> which would have been expanded is in a system header?
>> I think that would end up being more confusing than helpful because it
>> suppresses some, but not all, loops involving system macros.
>> I would put more effort into this if I thought it was generally
>> useful, but the fact that it isn't on by default, and that the headers
>> included with clang manage to trigger it, and there isn't any specific
>> class of users this is useful for, all indicate it isn't worth the
>> effort.
> If others agree with this argument, I can see a strong argument here to
> remove the warning entirely.

This thread clarifies why the warning is very important for a class of
users and why to reach the same aim has no pratical alternatives


Please do not remove it.

Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com

More information about the cfe-commits mailing list