Interestingly if I take your example:

%%
Start: Bar;
Foo: "a" | ;
Bar: Foo | Foo Bar;

and run it on (traditional-ish) yacc I get:

yacc: 1 rule never reduced
tmp.y: yacc finds 2 shift/reduce conflicts
tmp.y: yacc finds 1 reduce/reduce conflict

but on Bison:

tmp.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr]
tmp.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
tmp.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
tmp.y:4.6-8: warning: rule useless in parser due to conflicts [-Wother]
    4 | Bar: Foo | Foo Bar;
      |    

In both cases we have a warning, not an error, but the yacc warning is IMHO clearer.

So we probably have two questions to think about:

1. Should this be an error or a warning?
2. What should we call it / pretty-print to the user etc?

I think if we want to turn it into a warning we need to do something about the infinitely growing action vector when it hits that state.

(Although I guess my program should probably refuse to try and parse files, unless the number of conflicts to ignore is set appropriately).

I'm not exactly sure what the right way to go about I would assume replacing it with State 0?

We should probably do whatever yacc/bison does, at least if we're in YaccKind::Original mode. In YaccKind::Grmtools I think I'd be fine with throwing an error.

I agree, in general with that (It seems like I overlooked the rule useless when I said bison produced no additional errors),
I think it at least is stretching my familiarity here with the existing code base to fix it in the way bison does.

I think at least the way this works in the bison way is by having states in the StateGraph which never get added to the StateTable. Where currently StateGraph and StateTable's StIdx if i understand are in 1:1 correspondence. But once we have states in the StateGraph which never enter into the StateTable I would think we'd need to shift indexes down whenever we skip a useless state.

For now though, I'm just going to work around it by not running generated parsers which have conflicts when the conflict limits are not specified (Should have probably been doing this already). So that i'm not in a rush to fix it, and can take the time to do it correctly.

Does that mean we should close this PR or ... ?

Sorry, that's a weird cultural thing of not being terribly direct,

I'm fine with closing it if you want to, there is perhaps some useful information here, but that doesn't actually disappear if we do.

OK, agreed, we might as well close this -- it'll still be here.