From tim@X2296  Sun Apr 27 22:12:49 1997
Received: from X2296 (ppp1558.on.sympatico.ca [206.172.249.22])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA22625
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 27 Apr 1997 22:12:45 -0700 (PDT)
Received: (from tim@localhost) by X2296 (8.7.6/8.7.3) id BAA00878; Mon, 28 Apr 1997 01:06:47 -0400 (EDT)
Message-Id: <199704280506.BAA00878@X2296>
Date: Mon, 28 Apr 1997 01:06:47 -0400 (EDT)
From: Tim.Vanderhoek@X2296
Reply-To: ac199@hwcn.org
To: FreeBSD-gnats-submit@freebsd.org
Cc: robert.corbett@eng.Sun.COM
Subject: yacc doesn't well parse recursivish errors
X-Send-Pr-Version: 3.2

>Number:         3403
>Category:       bin
>Synopsis:       yacc doesn't well parse recursivish errors
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 27 22:20:01 PDT 1997
>Closed-Date:    Tue Apr 29 22:19:47 MEST 1997
>Last-Modified:  Tue Apr 29 22:20:04 MEST 1997
>Originator:     Tim Vanderhoek
>Release:        FreeBSD 2.2-961006-SNAP i386
>Organization:
The league of those who hack with yacc when they should be
studying for their upcoming Bible test...
>Environment:

Reasonably current yacc from FreeBSD-current...  The yacc is more current
than the Release line of this pr would suggest...

>Description:

It would seem that yacc doesn't properly handle rules along the lines
of

a: a error

when multiple errors occur.

Cc'd to robert.corbett@eng.Sun.COM (although I don't know if send-pr
will strip that or not...)


>How-To-Repeat:

The following program should print out have the following output:

--
Parsed #1
Parsed #0
--

However, it does not.  Rather, only the first line ("Parsed #1") is
printed...  This is not what I want the program to do.

It works correctly when one uses Bison (--version: GNU Bison version 1.25)
to generate the parser.  (If you try this, don't forget to give the -t
argument to bison).

Follows brief explanation of what goes wrong...

It correctly shifts into state 1 (a : X . a error) for the first X,
and then shifts into state 1 again for the second X.  The Y token is
returned and it correctly reduces an `a', and then an error, and finally
reduces from state 5 (X a error .) all the way back to state 4 (X a . error)
to finish off the first X statement.  The error recovery correctly
generates an error, however, this time it _DOES NOT_ shift from state 4
to state 5 on the error.

Bison does exactly the same thing, except for the fact that it does shift
on the second error the way it is supposed to...  :)

--
%{
#include <stdio.h>
%}

%union {
	int exp;
}

%token <exp> X
%token Y
%token NOSUCHTOKEN
%token ERROR

%%
a: Y {}  /* Hmm...  can't use a simple "empty" here...  */
	| X a NOSUCHTOKEN {}
	| X a error { fprintf (stderr, "Parsed #%d\n", $1); }
;

%%

main () { 
	yydebug = atoi(getenv("YYDEBUG") ? getenv("YYDEBUG") : ""); /* Bison */
	yyparse ();
}

yylex () {
	static p = 0;
	const int tok[] = {X, X, Y, ERROR, ERROR, ERROR, 0};

	if (tok[p] == X) yylval.exp = p;
	return tok[p++];
}

yyerror() {}
--

>Fix:

Heh.  My head's still spinning after spending most of today tracing this
one down...
>Release-Note:
>Audit-Trail:

From: hoek@hwcn.org
To: freebsd-gnats-submit@freebsd.org, Tim.Vanderhoek@X2296
Cc: ac199@hwcn.org, robert.corbett@eng.Sun.COM
Subject: Re: bin/3403: yacc doesn't well parse recursivish errors
Date: Tue, 29 Apr 1997 03:33:38 -0400 (EDT)

 >   Description
 >          
 >
 >It would seem that yacc doesn't properly handle rules along the lines
 >of
 
 Well....maybe it does...
 
 
 >The following program should print out have the following output:
 >
 >--
 >Parsed #1
 >Parsed #0
 >--
 >
 >However, it does not.  Rather, only the first line ("Parsed #1") is
 >printed...  This is not what I want the program to do.
 
 Nevermind...  It works just finely when one remembers to include yyerrok;
 in the error-handling rule.  Something still feels wrong, but I'm not that
 this bugreport quite points it out...
 
 Feel free to close it...
 
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Tue Apr 29 22:19:47 MEST 1997 
State-Changed-Why:  
Closed at Tim's request. 

>Unformatted:
