Re: get -Wyacc out of -Wall (was: RFC: explicit empty right-hand side of a rule)

[Akim Demaille]

Le 6 févr. 2013 à 01:44, Joel E. Denny <address@hidden> a écrit :

>>>>> Also, in gcc and clang, -Wall does not include the default warnings.  
>>>>> It's a separate category.  Quite a misnomer.  Maybe we should just not 
>>>>> have a -Wall.
>>>> 
>>>> We already have one.  I have tried to model Bison's diagnostic interface
>>>> to the one of gcc/clang.  In this regard, it would be weird not to support
>>>> -Wall, which is fairly traditional.
>>> 
>>> I misunderstood your proposal when you mentioned -Weverything.  I realize 
>>> now you meant that -Wempty-rule would be included in -Weverything but not 
>>> in -Wall because the latter might be in widespread use.  Right?
>>> 
>>> If we really want -Wall to work like gcc's, then should -Wno-all also 
>>> behave like gcc's?  That is, perhaps it shouldn't disable default 
>>> warnings?
>> 
>> I am not yet convinced that we really want something
>> more than -Wall, I was thinking aloud, throwing ideas
>> to see if someone picks them :)
>> 
>> Do you think we should go in that direction?
> 
> How about the following proposal?
> 
> 1. -Wall will continue to mean all warnings rather than trying to mimic 
> gcc's -Wall.  If someone specifies -Wall, he has no right to complain that 
> it enables a warning (such as -Wempty-rule) that he doesn't find useful.  
> He explicitly requested all warnings that Bison provides and might ever 
> provide.

Now that I see a means to escape from Autoconf's dictate to use -y
(by passing -o y.tab.c instead), I have started to see where -Wyacc
should be used.  But that triggers many warnings in Bison grammars,
because of -Wyacc is part of -Wall.  I don't think -Wall should
include -Wyacc, that's really something different.

Would someone object if -Wall meant "enable all the warnings except
-Wyacc"?