[Menhir-list] Error reporting
remi.dewitte at gide.net
Thu Feb 10 16:15:00 CET 2011
Hum ok :) Not sure I can manage to do this.
I tried a simple modification in codeBackend.ml
I replaced line 1623:
let s = Printf.sprintf "Node %d state %s isymbol %s"
(Lr0.print (Lr1.state s))
(match Lr1.incoming_symbol s with Some sym -> Symbol.print sym
| None -> "-" )
EApp (EVar "failwith" , [(EStringConst s)])
But from preliminary tests, it does not give really accurate info probably
because of how the LR parser works (as far as I understand it).
I'll try to understand more deeply what you suggest.
On Thu, Feb 10, 2011 at 15:10, Francois Pottier
<Francois.Pottier at inria.fr>wrote:
> On Thu, Feb 10, 2011 at 01:29:35PM +0100, Rémi Dewitte wrote:
> > How hard do you think it will be ?
> > If you could give few hints about how to get started to implement this
> > feature, I might try.
> I am not quite sure.
> The supposedly easy part would be to statically compute, for each state of
> the automaton, which set of tokens it is willing to accept. That would be
> the set of all tokens for which there exists either an outgoing transition
> (a shift action) or a reduction.
> However, even this part is not so easy as it sounds. This computation would
> produce an exact answer only if a canonical LR(1) construction has been
> carried out. However, as soon as one merges states (as done by SLR, LALR,
> Pager, etc.), one obtains states that appear to be willing to perform a
> reduction on a certain token T, yet that reduction will lead to a state
> the token T is rejected. Thus, the computation described in the previous
> paragraph will produce an over-approximation of the sets of acceptable
> (This would perhaps not be a problem in practice?)
> Then, the somewhat harder part would be to modify the two back-ends (the
> code-based back-end and the table-based back-end). The idea would be to let
> the SyntaxError exception carry the number of the state where an error was
> detected, and to provide a function that maps state numbers to sets of
> acceptable tokens. One would need to make sure that there is no interaction
> with the somewhat complicated mechanisms associated with the "error" token.
> François Pottier
> Francois.Pottier at inria.fr
> Menhir-list mailing list
> Menhir-list at yquem.inria.fr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Menhir-list