[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] -Werror: fix for rules useless in parser after conflicts.
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] -Werror: fix for rules useless in parser after conflicts. |
Date: |
Mon, 2 Aug 2010 22:27:11 -0400 (EDT) |
User-agent: |
Alpine 1.00 (DEB 882 2007-12-20) |
On Mon, 2 Aug 2010, Paul Eggert wrote:
> On 08/01/10 21:36, Joel E. Denny wrote:
> > it seems that any diagnostic printed
> > on stderr is at least a warning, and I can see how the user might
> > appreciate a guarantee that -Werror will prevent him from missing any such
> > diagnostic. That seems to be the thinking at comp.compilers.
>
> It also sounds reasonable to me.
Also, we can consider that -Werror is really a tool for the *maintainers*
of any project that depends on bison. That is, a formal release of such a
project should either distribute the output of bison so that the release
does not require users to run bison, or -Werror should be turned off by
default in the release. Otherwise, in general, users who install a new
bison with new warnings will see build failures for the project. From
that viewpoint, there is no legitimate backward compatibility issue to
consider here. We can feel free to promote conflicts to warnings.
Nevertheless, we might lose a desired -Werror use case. That is, there
might be maintainers of projects that depend on bison who argue that they
want -Werror for all the other warnings from bison. However, because
conflicts are inherent in the design of their grammars and fluctuate
significantly as the grammar evolves, they don't want to be forced to fuss
with maintaining a count in %expect or %expect-rr in order to suppress the
conflict warning. To satisfy them, we could add a -Wconflicts that would
be on by default. They could then combine -Werror with -Wno-conflicts.
Such a maintainer might appreciate being able to use -Wno-conflicts to
fully suppress the conflicts report in a formal release anyway.
Actually, we should probably split -Wconflicts into -Wconflicts-sr and
-Wconflicts-rr given that S/R and R/R conflicts are usually considered to
be very different levels of severity.
Regardless of the absence of any backward compatibility issue,
-Wconflicts-rr and -Wconflicts-sr feel too much like new features to be in
2.4.3. They can wait for 2.5 or 2.6.
> If this turns into a hardship, we
> could add some complexity by having levels of warnings, and report
> only "serious" warnings as errors, or something like that. But I
> hope such complexity isn't needed.
That's essentially what we have now. The non-serious level just doesn't
have much in it.