]> git.saurik.com Git - bison.git/blobdiff - NEWS
yysyntax_error: fix for consistent error with lookahead.
[bison.git] / NEWS
diff --git a/NEWS b/NEWS
index 5799790572eb10a4496e356915f62c666bf105cc..c8188395f01d6b227d8c5fe997ac697787491a8b 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -6,7 +6,7 @@ Bison News
 ** Additional yylex/yyparse arguments
 
   The new directive %param declare additional argument to both yylex
-  and yyparse.  The %lex-param, %parse-param, and %param directive
+  and yyparse.  The %lex-param, %parse-param, and %param directives
   support one or more arguments.  Instead of
 
       %lex-param   {arg1_type *arg1}
@@ -51,6 +51,15 @@ Bison News
   use of the %error-verbose directive is deprecated in favor of
   %define parse.error "verbose".
 
+** Semantic predicates
+
+  The new, experimental, semantic-predicate feature allows actions of
+  the form %?{ BOOLEAN-EXPRESSION }, which cause syntax errors (as for
+  YYERROR) if the expression evaluates to 0, and are evaluated immediately
+  in GLR parsers, rather than being deferred.  The result is that they
+  allow the programmer to prune possible parses based on the values of
+  runtime expressions.
+
 * Changes in version 2.5 (????-??-??):
 
 ** Named References Support
@@ -214,14 +223,41 @@ Bison News
   Bison now warns when a character literal is not of length one.  In
   some future release, Bison will report an error instead.
 
-** Verbose error messages fixed for nonassociative tokens.
-
-  When %error-verbose is specified, syntax error messages produced by
-  the generated parser include the unexpected token as well as a list of
-  expected tokens.  Previously, this list erroneously included tokens
-  that would actually induce a syntax error because conflicts for them
-  were resolved with %nonassoc.  Such tokens are now properly omitted
-  from the list.
+** Verbose syntax error message fixes:
+
+  When %error-verbose or `#define YYERROR_VERBOSE' is specified, syntax
+  error messages produced by the generated parser include the unexpected
+  token as well as a list of expected tokens.  The effect of %nonassoc
+  on these verbose messages has been corrected in two ways, but
+  additional fixes are still being implemented:
+
+*** When %nonassoc is used, there can exist parser states that accept no
+    tokens, and so the parser does not always require a lookahead token
+    in order to detect a syntax error.  Because no unexpected token or
+    expected tokens can then be reported, the verbose syntax error
+    message described above is suppressed, and the parser instead
+    reports the simpler message, "syntax error".  Previously, this
+    suppression was sometimes erroneously triggered by %nonassoc when a
+    lookahead was actually required.  Now verbose messages are
+    suppressed only when all previous lookaheads have already been
+    shifted or discarded.
+
+*** Previously, the list of expected tokens erroneously included tokens
+    that would actually induce a syntax error because conflicts for them
+    were resolved with %nonassoc in the current parser state.  Such
+    tokens are now properly omitted from the list.
+
+*** Expected token lists are still often wrong due to state merging
+    (from LALR or IELR) and default reductions, which can both add and
+    subtract valid tokens.  Canonical LR almost completely fixes this
+    problem by eliminating state merging and default reductions.
+    However, there is one minor problem left even when using canonical
+    LR and even after the fixes above.  That is, if the resolution of a
+    conflict with %nonassoc appears in a later parser state than the one
+    at which some syntax error is discovered, the conflicted token is
+    still erroneously included in the expected token list.  We are
+    currently working on a fix to eliminate this problem and to
+    eliminate the need for canonical LR.
 
 ** Destructor calls fixed for lookaheads altered in semantic actions.
 
@@ -230,7 +266,75 @@ Bison News
   determine which destructor to call for the lookahead upon a syntax
   error or upon parser return.  This bug has been fixed.
 
-* Changes in version 2.4.2 (????-??-??):
+** C++ parsers use YYRHSLOC
+
+  Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
+  macro and use it in the default YYLLOC_DEFAULT.  You are encouraged
+  to use it.  If, for instance, your location structure has "first"
+  and "last" members, instead of
+
+      # define YYLLOC_DEFAULT(Current, Rhs, N)                             \
+        do                                                                 \
+          if (N)                                                           \
+            {                                                              \
+              (Current).first = (Rhs)[1].location.first;                   \
+              (Current).last  = (Rhs)[N].location.last;                    \
+            }                                                              \
+          else                                                             \
+            {                                                              \
+              (Current).first = (Current).last = (Rhs)[0].location.last;   \
+            }                                                              \
+        while (false)
+
+  use:
+
+      # define YYLLOC_DEFAULT(Current, Rhs, N)                             \
+        do                                                                 \
+          if (N)                                                           \
+            {                                                              \
+              (Current).first = YYRHSLOC (Rhs, 1).first;                   \
+              (Current).last  = YYRHSLOC (Rhs, N).last;                    \
+            }                                                              \
+          else                                                             \
+            {                                                              \
+              (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last;   \
+            }                                                              \
+        while (false)
+
+** YYLLOC_DEFAULT in C++
+
+  The default implementation of YYLLOC_DEFAULT used to be issued in
+  the header file.  It is now output in the implementation file, after
+  the user %code sections so that its #ifndef guard does not try to
+  override the user's YYLLOC_DEFAULT if provided.
+
+* Changes in version 2.4.3 (2010-08-05):
+
+** Bison now obeys -Werror and --warnings=error for warnings about
+   grammar rules that are useless in the parser due to conflicts.
+
+** Problems with spawning M4 on at least FreeBSD 8 and FreeBSD 9 have
+   been fixed.
+
+** Failures in the test suite for GCC 4.5 have been fixed.
+
+** Failures in the test suite for some versions of Sun Studio C++ have
+   been fixed.
+
+** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
+   warnings about undefined %prec identifiers will not be converted to
+   errors in Bison 2.5.  They will remain warnings, which should be
+   sufficient for POSIX while avoiding backward compatibility issues.
+
+** Minor documentation fixes.
+
+* Changes in version 2.4.2 (2010-03-20):
+
+** Some portability problems that resulted in failures and livelocks
+   in the test suite on some versions of at least Solaris, AIX, HP-UX,
+   RHEL4, and Tru64 have been addressed.  As a result, fatal Bison
+   errors should no longer cause M4 to report a broken pipe on the
+   affected platforms.
 
 ** `%prec IDENTIFIER' requires IDENTIFIER to be defined separately.
 
@@ -241,6 +345,8 @@ Bison News
   %prec directive.  It is now restored.  However, for backward
   compatibility with recent Bison releases, it is only a warning for
   now.  In Bison 2.5 and later, it will return to being an error.
+  [Between the 2.4.2 and 2.4.3 releases, it was decided that this
+  warning will not be converted to an error in Bison 2.5.]
 
 ** Detection of GNU M4 1.4.6 or newer during configure is improved.
 
@@ -1364,7 +1470,8 @@ End:
 -----
 
 Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
-2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
+Inc.
 
 This file is part of Bison, the GNU Parser Generator.