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

Ted Kremenek kremenek at apple.com
Mon Oct 29 21:07:55 PDT 2012


On Oct 29, 2012, at 8:38 PM, Eli Friedman <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121029/564254e7/attachment.html>


More information about the cfe-commits mailing list