bison-patches
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]