Re: warning flags in 2.4.1

[Joel E. Denny]

Hi George,

On Sun, 1 Aug 2010, George Neuner wrote:

> I don't know if these are bugs or misunderstandings:

I investigated this some over the weekend and went ahead and started a 
thread at:

  http://lists.gnu.org/archive/html/bison-patches/2010-08/msg00000.html

> On page 114 of the PDF manual it says that the command line option
> "--warnings=error" or "-Werror" should force bison to treat warnings as
> errors.  I interpret that to mean that, if a warning is generated, bison
> should exit with a non-zero (fail) return code - just as it does if a fatal
> problem prevents the parser from being generated.

Right.

> This does not work as I
> expect - the return code is always zero if the parser can be generated.

-Werror does turn a few warnings into errors with a non-zero return code, 
but those warnings are not as common as the warnings you've encountered.

> Also on page 114, the manual says "--warnings=none" or "-Wnone" should
> suppress all warnings.  This does not work.  Grammar warnings, if any, are
> generated regardless of this setting.

Thanks for mentioning that.  I hadn't noticed it before, and I agree it is 
confusing.  I think the idea was that -Wnone (or --warnings=none) simply 
disables all warnings that can be enabled by the other -W options.  It's 
not clear to me if the documentation or the behavior needs to be fixed 
here.

> These situations can be reproduced using any grammar with a R/R conflict or an
> unexpected S/R conflict.

As you'll see in the other thread, bison hasn't previously labeled the 
count of conflicts as a warning.  Given that it's a diagnostic printed on 
stderr, we're now considering whether it should be labeled as a warning 
and thus affected by -Werror.

> I believe mismatched (too many or not enough
> expected) S/R warnings also should fail if "warnings=error" is selected.

By "mismatched", are you referring to the case where either %expect or 
%expect-rr is specified?  In that case, an incorrect number of conflicts 
produces an error not a warning, so -Werror becomes irrelevant.  Our 
manual unfortunately uses the word "warn" in at least one context, so that 
needs to be fixed.

> I don't mind if the parser is generated for the "--warnings=error" case ...
> but the result code should indicate the condition.  I've only ever seen '0'
> and '1' as result codes ... perhaps a new code value should be introduced to
> mean success but with warnings.

The norm is for warnings to produce a 0 result unless -Werror is in 
effect.  Bison probably shouldn't change this practice as it could cause 
make files to fail unexpectedly.

> Hope this helps,

Yes.  Thanks for the report.