Re: [PATCH] -Werror: fix for rules useless in parser after conflicts.

[George Neuner]

In message: 
http://lists.gnu.org/archive/html/bison-patches/2010-08/msg00003.html
Joel said:
> 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.

That sounds quite reasonable ... so long as the documentation is clear about
what each switch does and what the defaults are.  The main issue from
comp.compilers was build control and the ability to know that the grammar is
broken (for various definitions of "broken") so a bad build can be prevented.

Bison (and Yacc before it) has (too) long required the extra step of searching
the output to catch conditions that don't prevent a parser from being
generated.  This is cumbersome in some GUI environments that permit only a
command line for invoking external tools.  Then you're not only maintaining
the GUI's build settings but also external scripts for running the tools.
Windows batch files can't even return a result code so there are extra
gyrations - different shell, scripting engine, special tool to set code, etc.
necessary to use Bison there.
[I know Windows isn't a priority for GNU but a lot of people do develop
there.]

To be sure, this issue is only an annoyance - but I think it's one that many
people can relate to.

George