On Sat, 13 Dec 2014 15:19:34 +0000 Sergei Trofimovich <sly...@gmail.com> wrote:
> On Wed, 03 Dec 2014 11:59:42 +0000 > Simon Marlow <marlo...@gmail.com> 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? > > 4 of reduce/reduce conflicts are result of exact rule copy: > https://phabricator.haskell.org/D569 > > > 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. > > Agreed. > > 11 more reduce/reduce (of left 12) came from single scary rule > added in > > commit bc2289e13d9586be087bd8136943dc35a0130c88 > > ghc generates more user-friendly error messages > > exp10 :: { LHsExpr RdrName } > ... > | 'let' binds {% parseErrorSDoc (combineLocs $1 $2) $ text > "parse error in let binding: missing required > 'in'" > } > > The other rules add shift/reduce conflicts as follows: > > -- parsing error messages go below here > {- s/r:1 r/r:0 -} > | '\\' apat apats opt_asig '->' {% parseErrorSDoc (combineLocs $1 $5) $ > text > "parse error in > lambda: no expression after '->'" > {- s/r:1 r/r:0 -} > | '\\' {% parseErrorSDoc (getLoc > $1) $ text > "parse error: naked > lambda expression '\'" > } > {- s/r:1 r/r:0 -} > | 'let' binds 'in' {% parseErrorSDoc > (combineLocs $1 $2) $ text > "parse error in let > binding: missing expression after 'in'" > } > {- s/r:0 r/r:11 -} > | 'let' binds {% parseErrorSDoc > (combineLocs $1 $2) $ text > "parse error in let > binding: missing required 'in'" > } > {- s/r:0 r/r:0 -} > | 'let' {% parseErrorSDoc > (getLoc $1) $ text > "parse error: naked > let binding" > } > {- s/r:1 r/r:0 -} > | 'if' exp optSemi 'then' exp optSemi 'else' {% hintIf (combineLocs > $1 $5) "else clause empty" } > {- s/r:2 r/r:0 -} > | 'if' exp optSemi 'then' exp optSemi {% hintIf (combineLocs > $1 $5) "missing required else clause" } > {- s/r:1 r/r:0 -} > | 'if' exp optSemi 'then' {% hintIf (combineLocs > $1 $2) "then clause empty" } > {- s/r:2 r/r:0 -} > | 'if' exp optSemi {% hintIf (combineLocs > $1 $2) "missing required then and else clauses" > {- s/r:2 r/r:0 -} > | 'if' {% hintIf (getLoc $1) > "naked if statement" } > {- s/r:0 r/r:0 -} > | 'case' exp 'of' {% parseErrorSDoc > (combineLocs $1 $2) $ text > "parse error in case > statement: missing list after '->'" > } > {- s/r:1 r/r:0 -} > | 'case' exp {% parseErrorSDoc > (combineLocs $1 $2) $ text > "parse error in case > statement: missing required 'of'" > } > {- s/r:1 r/r:0 -} > | 'case' {% parseErrorSDoc > (getLoc $1) $ text > "parse error: naked > case statement" > } > > Shift/reduces look harmless (like MultiWayIf ambiguity) > as they seem to resolve as shift correctly. Proposed fix as: https://phabricator.haskell.org/D571 Simon, is using happy's "error" token the proper way of fixing these error reporting rules? Thanks! -- Sergei
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs