reduce/reduce conflicts are bad, especially so since they're
undocumented. We don't know whether this introduced parser bugs or not.
Mike - could you look at this please? It was your commit that
introduced the new conflicts.
Cheers,
Simon
On 02/12/2014 10:19, Dr. ERDI Gergo wrote:
On Mon, 1 Dec 2014, Richard Eisenberg wrote:
In unrelated work, I saw this scroll across when happy'ing the parser:
shift/reduce conflicts: 60
reduce/reduce conflicts: 16
These numbers seem quite a bit higher than what I last remember (which
is something like 48 and 1, not 60 and 16). Does anyone know why?
The offending commit is bc2289e13d9586be087bd8136943dc35a0130c88. I know
this because I was changing the parser for patsyn signatures, and so I
updated the numbers in Parser.y to make sure I'm not adding any new
conflicts:
25 June 2014
Conflicts: 47 shift/reduce
1 reduce/reduce
but then when time came to rebase my changes before pushing, I noticed
that it has gone up, and I had to update it yet again in Parser.y:
20 Nov 2014
Conflicts: 60 shift/reduce
12 reduce/reduce
So anyway, the point is, if you try bc2289e and bc2289e^ you can see
that that is the commit that introduced these new conflicts.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
