Re: Useless conflict in bison 2.4.2, while 2.3 is happy

[Joel E. Denny]

On Thu, 15 Jul 2010, Wilson Snyder wrote:

> Thanks, yes 
> 
>  %define lr.keep_unreachable_states

Oops, yes, that's how you spell it in 2.4.2.  2.5 will provide the nicer 
spelling (dashes instead of underscores), but the old spelling will be 
supported indefinitely.

> works around the issue.  However, this source code is open
> sourced, and runs against many versions of bison.  Presuming
> for a moment I wanted to really use this define, how would I
> prevent this define from causing a syntax error on earlier
> versions?

You could extend your project's configure script to check for this 
feature.  It could then transform grammar.y.in into grammar.y by replacing 
@BISON_KEEP_UNREACHABLE_STATES@ with either the above directive or the 
empty string.

> More importantly, I still don't see why these rules are
> useless.  Can you or someone please take a look at the
> grammar?

I'm afraid I don't have time at the moment, but maybe I can make some 
helpful suggestions....

These rules are useless because they appear in unreachable states.  A 
state becomes unreachable when a S/R conflict is resolved as a reduce or 
as an error and when the shift was the last way to reach that state.

Currently, Bison does not detect states that become unreachable due to the 
removal of reduces, so you can be sure that's not the cause.

I think you named about 6 states that are removed.  I recommend you 
comment out all precedence declarations in your grammar and then generate 
the automaton report with --report=all.  Next, search the report for 
states that have shift actions to the states that were previously removed.  
Those states represent the contexts in which the decision is being made to 
discard the rules.

> Also, is there some way to get more verboseness in why a
> rule is considered useless - what it overlaps against, for
> example, in the way that reduce-reduce conflicts do?
> Otherwise it's extremely hard to figure out what's wrong in
> a grammar this size.

Unfortunately, Bison doesn't produce any additional information at the 
moment.  A helpful starting point would be if Bison could list example 
token sequences that lead to any particular state.  This would help users 
to understand what context a state represents once they've identified 
states using a procedure like the one I described above.

However, Bison can generate its automaton report in XML, which should make 
it easier to write helpful analysis tools.  If you decide to explore that 
possibility, let us know what you come up with.