In verbose parse error message, don't report `error' as an

expected token.
* tests/actions.at (Printers and Destructors): Adjust.
* tests/calc.at (Calculator $1): Adjust.
* data/yacc.c, data/glr.c, data/lalr1.c: When making the verbose
error message, do not report the parser accepts the error token in
that state.

ChangeLog

@@ -1,3 +1,13 @@
+2002-07-30  Akim Demaille  <akim@epita.fr>
+
+	In verbose parse error message, don't report `error' as an
+	expected token.
+	* tests/actions.at (Printers and Destructors): Adjust.
+	* tests/calc.at (Calculator $1): Adjust.
+	* data/yacc.c, data/glr.c, data/lalr1.c: When making the verbose
+	error message, do not report the parser accepts the error token in
+	that state.
+
 2002-07-30  Akim Demaille  <akim@epita.fr>
 
 	Normalize conflict related messages.

NEWS

@@ -30,6 +30,13 @@ Changes in version 1.49b:
   user specified that one of her tokens is numbered 256, then error
   will be mapped onto another number.
 
+* Verbose error messages
+  They no longer report `..., expecting error or...' for state where
+  error recovery is possible.
+
+* End token
+  Defaults to `$end' instead of `$'.
+
 * Error recovery now conforms to documentation and to POSIX
   When a Bison-generated parser encounters a syntax error, it now pops
   the stack until it finds a state that allows shifting the error
@@ -84,7 +91,7 @@ Changes in version 1.49b:
 * Token end-of-file
   The token end of file may be specified by the user, in which case,
   the user symbol is used in the reports, the graphs, and the verbose
-  error messages instead of `$', which remains being the defaults.
+  error messages instead of `$end', which remains being the defaults.
   For instance
      %token YYEOF 0
   or

TODO

@@ -16,30 +16,6 @@ Some are really funky.  For instance
 
 is really weird.  Revisit them all.
 
-* Stupid error messages
-An example shows it easily:
-
-src/bison/tests % ./testsuite -k calc,location,error-verbose -l
-GNU Bison 1.49a test suite test groups:
-
- NUM: FILENAME:LINE      TEST-GROUP-NAME
-      KEYWORDS
-
-  51: calc.at:440        Calculator --locations --yyerror-verbose
-  52: calc.at:442        Calculator --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
-  54: calc.at:445        Calculator --debug --defines --locations --name-prefix=calc --verbose --yacc --yyerror-verbose
-src/bison/tests % ./testsuite 51 -d
-## --------------------------- ##
-## GNU Bison 1.49a test suite. ##
-## --------------------------- ##
- 51: calc.at:440       ok
-## ---------------------------- ##
-## All 1 tests were successful. ##
-## ---------------------------- ##
-src/bison/tests % cd ./testsuite.dir/51
-tests/testsuite.dir/51 % echo "()" | ./calc
-1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('
-
 
 * read_pipe.c
 This is not portable to DOS for instance.  Implement a more portable

data/glr.c

@@ -1512,7 +1512,7 @@ yyreportParseError (yyGLRStack* yystack, YYSTYPE* yylvalp, YYLTYPE* yyllocp)
 	  yyprefix = ", expecting ";
 	  for (yyx = yyn < 0 ? -yyn : 0; yyx < yytname_size && yycount <= 5;
 	       yyx += 1)
-	    if (yycheck[yyx + yyn] == yyx)
+	    if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR)
 	      yysize += strlen (yytokenName (yyx)) + strlen (yyprefix),
 		yycount += 1, yyprefix = " or ";
 	  yymsg = yyp = (char*) malloc (yysize);

data/lalr1.cc

@@ -500,13 +500,13 @@ yy::b4_name::parse ()
 	  {
 	    int count = 0;
 	    for (int x = (n_ < 0 ? -n_ : 0); x < ntokens_ + nnts_; ++x)
-	      if (check_[[x + n_]] == x)
+	      if (check_[[x + n_]] == x && x != terror_)
 		++count;
 	    if (count < 5)
 	      {
 		count = 0;
 		for (int x = (n_ < 0 ? -n_ : 0); x < ntokens_ + nnts_; ++x)
-		  if (check_[[x + n_]] == x)
+		  if (check_[[x + n_]] == x && x != terror_)
 		    {
 		      message += (!count++) ? ", expecting " : " or ";
 		      message += name_[[x]];

data/yacc.c

@@ -667,7 +667,7 @@ b4_c_function([yyreport_parse_error],
 	 YYCHECK.  */
       for (yyx = yyn < 0 ? -yyn : 0;
 	   yyx < (int) (sizeof (yytname) / sizeof (char *)); yyx++)
-	if (yycheck[yyx + yyn] == yyx)
+	if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR)
 	  yysize += yystrlen (yytname[yyx]) + 15, yycount++;
       yysize += yystrlen ("parse error, unexpected ") + 1;
       yysize += yystrlen (yytname[yytype]);
@@ -683,7 +683,7 @@ b4_c_function([yyreport_parse_error],
 	      for (yyx = yyn < 0 ? -yyn : 0;
 		   yyx < (int) (sizeof (yytname) / sizeof (char *));
 		   yyx++)
-		if (yycheck[yyx + yyn] == yyx)
+		if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR)
 		  {
 		    const char *yyq = ! yycount ? ", expecting " : " or ";
 		    yyp = yystpcpy (yyp, yyq);

tests/actions.at

@@ -327,7 +327,7 @@ thing(10): 'x'(10)
 sending: ';' (value = 11, line 110)
 line(10): thing(10) ';'
 sending: 'y' (value = 12, line 120)
-120: parse error, unexpected $undefined, expecting $end or error or 'x'
+120: parse error, unexpected $undefined, expecting $end or 'x'
 sending: EOF
 Freeing nterm line (10 from 100)
 Freeing nterm line (7 from 70)

tests/calc.at

@@ -419,7 +419,7 @@ calc: error: 0 != 1])
 # Add a studid example demonstrating that Bison can further improve the
 # error message.  FIXME: Fix this ridiculous message.
 _AT_CHECK_CALC_ERROR([$1], [()], [21],
-[1.2-1.3: parse error, unexpected ')', expecting error or "number" or '-' or '('])
+[1.2-1.3: parse error, unexpected ')', expecting "number" or '-' or '('])
 
 AT_CLEANUP
 ])# AT_CHECK_CALC