more parser conflicts?
Sergei Trofimovich
slyich at gmail.com
Sun Dec 14 17:07:02 UTC 2014
On Sat, 13 Dec 2014 15:19:34 +0000
Sergei Trofimovich <slyich at gmail.com> wrote:
> On Wed, 03 Dec 2014 11:59:42 +0000
> Simon Marlow <marlowsd at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141214/a8c616ea/attachment.sig>
More information about the ghc-devs
mailing list