Give more descriptive warnings on shift/reduce conflicts

[mrgleba]

Give more detail about shift/reduce and reduce/reduce and state explicitely which is eventually chosen.

Give extra info in warning when we have a shift/reduce on an explicitely nonassoc.

[dsyme]

Thanks!

[kkm000]

@dsyme, @mrgleba, is this related to/fixes/addresses #39 and #40? I know too little not only to fix these issues, but also to even understand the problem.

[mrgleba]

Well, the commit doesn't alter the parser in any way it only improves the way the conflicts are reported.
It's generally a non-breaking change. The generated parser itself is not changed in any way.

As regards #39:
Using a nonnasoc in this way is rather bogus. Generally arithmetics and logics are done in their own rules. IMHO accomodating FsLexyacc to accept this beahviour would be doing a lot of work (and I mean wild changes in the construction of the automaton) just to allow bad beahviour. Unless there is a really compelling exaplce to the contrary I believe this is a clear WontFix.

#40 is a horse of a whole diferent colour.
Right now in fslexyacc rule precedence is determined by

• %prec TERMINAL if given
  • last TERMINAL (ie token rather than clause) in the rule

Rule precedence as of now are used in shift/reduce conflicts and completely ignored in reduce/reduce where the rule earlier in the file wins. This is IMHO a bug.
I'll make a pull request with a patch in a minute and we can discuss that there.

[TorbenMogensen]

See my comments on #39 for why I disagree that the proposed change is "bogus". Note that I don't have privileges to reopen #39, so I ask someone who can to do so.