Re: Reductions during Bison error handling

[Paul Hilfinger]

 > You may be right, but I would like to see what the actual change is.

Basically, we take the section of bison.simple that now reads

    yyerrhandle:
      yyn = yypact[yystate];
      if (yyn == YYFLAG)
        goto yyerrdefault;

      yyn += YYTERROR;
      if (yyn < 0 || yyn > YYLAST || yycheck[yyn] != YYTERROR)
        goto yyerrdefault;

      yyn = yytable[yyn];
!     if (yyn < 0)                      
!       {
!         if (yyn == YYFLAG)
!           goto yyerrpop;
!         yyn = -yyn;
!         goto yyreduce;
!       }
!     else if (yyn == 0)
        goto yyerrpop;

      if (yyn == YYFINAL)

and replace the ! lines with just

      if (yyn <= 0)

(There is a more elaborate change proposed, but it is equivalent to
this and is otherwise just a clean-up).

The effect is that when a syntax error is discovered, we would now pop
the stack back to where 'error' can be shifted, shift it, and then
continue (the standard yacc panic-mode error recovery, in other
words).  By contrast, the current code will, after popping stack
symbols but before shifting error, sometimes perform additional
reductions (as a result of which it may never shift error or take the
error action at all.)  I sent a contrived example a couple of weeks
ago (below).

Paul H.

----------------------------------------------------------------------

To: Hans Aberg <address@hidden>
cc: address@hidden, address@hidden
Subject: Re: Reductions during Bison error handling 
Reply-To: address@hidden
Date: Fri, 10 May 2002 20:35:27 -0700


As further evidence that perhaps something odd is going on, here is an
example where there is a parse error; it is recovered from; but 
Bison never uses the error production!


    prog: 'x' 'y' 'z' ';' { printf (" x y z ;\n"); }
        | r error ';' { printf (" *err*\n"); }
        | r 'x' ';'  { printf (" x x ;\n"); }
        | q ';'
        | q '.' 
        ;

    q : 'x' 
      ;

    r : 'x' 
      ;


With the input 

     x y x ;

we get the output

     Error: parse error
     x x ;

indicating that 'error' was never shifted. 

Why?  Well, when we pop the stack back to the first 'x' and take the 
reduction r : 'x' (which is indicated when the lookahead token is
error),  the algorithm I sent in the last message has us "proceeding
normally", meaning that we use the current lookahead symbol ('x').

Paul Hilfinger