[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: warning flags in 2.4.1
From: |
Joel E. Denny |
Subject: |
Re: warning flags in 2.4.1 |
Date: |
Wed, 4 Aug 2010 20:50:20 -0400 (EDT) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
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