On Mon, 2 Aug 2010, Joel E. Denny wrote: > > 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.
Any opinions on this from anyone? If we decide that -Wnone should affect all warnings, then we probably need to add some kind of -Wother option for all warnings that do not have their own -W option. The documentation should make it clear that we might later move warnings from -Wother to new, more specific -W options. Regardless of which functionality we pick for -Wnone, it probably should not affect -Werror. Currently, it disables it. Even if we decide that -Wnone should disable all warnings, it still should not affect -Werror in the following case: bison -Werror -Wnone -Wyacc parser.y That is, POSIX Yacc warnings would be the only warnings and would be treated as errors. I have a feeling we're not going to settle this issue soon, and I want to release 2.4.3 tomorrow. I'm thinking of adding a note to the manual that explains that -Wnone functionality is currently broken. We can fix it for 2.5. > 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. To fix that and another documentation error, I pushed the following patch to branch-2.4.3, branch-2.5, and master. >From 3ffdd5f1254fd9403a5a1d31dbdc5b2756c22775 Mon Sep 17 00:00:00 2001 From: Joel E. Denny <[email protected]> Date: Wed, 4 Aug 2010 20:17:40 -0400 Subject: [PATCH] doc: fix -W and %expect documentation some. * NEWS (2.4.3): Mention that there are documentation fixes. * doc/bison.texinfo (Expect Decl): Make it clear that %expect turns conflicts into errors not warnings. (Shift/Reduce): Likewise. (Bison Options): Don't mention -Wsyntax. It doesn't exist. --- ChangeLog | 9 +++++++++ NEWS | 2 ++ doc/bison.texinfo | 14 ++++++++------ 3 files changed, 19 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index d365830..58745bb 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2010-08-04 Joel E. Denny <[email protected]> + + doc: fix -W and %expect documentation some. + * NEWS (2.4.3): Mention that there are documentation fixes. + * doc/bison.texinfo (Expect Decl): Make it clear that %expect + turns conflicts into errors not warnings. + (Shift/Reduce): Likewise. + (Bison Options): Don't mention -Wsyntax. It doesn't exist. + 2010-08-01 Joel E. Denny <[email protected]> -Werror: fix for rules useless in parser after conflicts. diff --git a/NEWS b/NEWS index 64a1ee6..afa975b 100644 --- a/NEWS +++ b/NEWS @@ -19,6 +19,8 @@ Bison News errors in Bison 2.5. They will remain warnings, which should be sufficient for POSIX while avoiding backward compatibility issues. +** Minor documentation fixes. + * Changes in version 2.4.2 (2010-03-20): ** Some portability problems that resulted in failures and livelocks diff --git a/doc/bison.texinfo b/doc/bison.texinfo index 4027388..405935c 100644 --- a/doc/bison.texinfo +++ b/doc/bison.texinfo @@ -4494,8 +4494,8 @@ number which Bison printed. With @acronym{GLR} parsers, add an @code{%expect-rr} declaration as well. @end itemize -Now Bison will warn you if you introduce an unexpected conflict, but -will keep silent otherwise. +Now Bison will report an error if you introduce an unexpected conflict, +but will keep silent otherwise. @node Start Decl @subsection The Start-Symbol @@ -6172,8 +6172,10 @@ This particular ambiguity was first encountered in the specifications of Algol 60 and is called the ``dangling @code{else}'' ambiguity. To avoid warnings from Bison about predictable, legitimate shift/reduce -conflicts, use the @code{%expect @var{n}} declaration. There will be no -warning as long as the number of shift/reduce conflicts is exactly @var{n}. +conflicts, use the @code{%expect @var{n}} declaration. +There will be no warning as long as the number of shift/reduce conflicts +is exactly @var{n}, and Bison will report an error if there is a +different number. @xref{Expect Decl, ,Suppressing Conflict Warnings}. The definition of @code{if_stmt} above is solely to blame for the @@ -7813,8 +7815,8 @@ Treat warnings as errors. @end table A category can be turned off by prefixing its name with @samp{no-}. For -instance, @option{-Wno-syntax} will hide the warnings about unused -variables. +instance, @option{-Wno-yacc} will hide the warnings about +...@acronym{posix} Yacc incompatibilities. @end table @noindent -- 1.7.0.4
