Re: warning flags in 2.4.1

[Joel E. Denny]

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 <address@hidden>
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  <address@hidden>
+
+       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  <address@hidden>
 
        -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
address@hidden Yacc incompatibilities.
 @end table
 
 @noindent
-- 
1.7.0.4