]> git.saurik.com Git - bison.git/blobdiff - NEWS
doc: create a new Tuning LR section in the manual.
[bison.git] / NEWS
diff --git a/NEWS b/NEWS
index 2f0711ea519150d0aac843a5091b9966643d0964..a657bcc85ed50955a8d44ae53341692e3c53b43d 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -3,7 +3,15 @@ Bison News
 
 * Changes in version 2.5 (????-??-??):
 
-** Named References Support
+** Grammar symbol names can now contain non-initial dashes:
+
+  Consistently with directives (such as %error-verbose) and with
+  %define variables (e.g. push-pull), grammar symbol names may contain
+  dashes in any position except the beginning.  This is a GNU
+  extension over POSIX Yacc.  Thus, use of this extension is reported
+  by -Wyacc and rejected in Yacc mode (--yacc).
+
+** Named references:
 
   Historically, Yacc and Bison have supported positional references
   ($n, $$) to allow access to symbol values from inside of semantic
@@ -28,13 +36,13 @@ Bison News
   These features are experimental in this version.  More user feedback
   will help to stabilize them.
 
-** IELR(1) and Canonical LR(1) Support
+** IELR(1) and canonical LR(1):
 
   IELR(1) is a minimal LR(1) parser table generation algorithm.  That
   is, given any context-free grammar, IELR(1) generates parser tables
   with the full language recognition power of canonical LR(1) but with
-  nearly the same number of parser states as LALR(1).  This reduction in
-  parser states is often an order of magnitude.  More importantly,
+  nearly the same number of parser states as LALR(1).  This reduction
+  in parser states is often an order of magnitude.  More importantly,
   because canonical LR(1)'s extra parser states may contain duplicate
   conflicts in the case of non-LR(1) grammars, the number of conflicts
   for IELR(1) is often an order of magnitude less as well.  This can
@@ -49,24 +57,58 @@ Bison News
     %define lr.type ielr
     %define lr.type canonical-lr
 
-  The default reduction optimization in the parser tables can also be
-  adjusted using `%define lr.default-reductions'.  See the documentation
-  for `%define lr.type' and `%define lr.default-reductions' in the
-  section `Bison Declaration Summary' in the Bison manual for the
-  details.
+  The default-reduction optimization in the parser tables can also be
+  adjusted using `%define lr.default-reductions'.  For details on both
+  of these features, see the new section `Tuning LR' in the Bison
+  manual.
 
   These features are experimental.  More user feedback will help to
   stabilize them.
 
-** Unrecognized %code qualifiers are now an error not a warning.
+** LAC (Lookahead Correction) for syntax error handling:
 
-** %define improvements.
+  Canonical LR, IELR, and LALR can suffer from a couple of problems
+  upon encountering a syntax error.  First, the parser might perform
+  additional parser stack reductions before discovering the syntax
+  error.  Such reductions can perform user semantic actions that are
+  unexpected because they are based on an invalid token, and they
+  cause error recovery to begin in a different syntactic context than
+  the one in which the invalid token was encountered.  Second, when
+  verbose error messages are enabled (with %error-verbose or the
+  obsolete `#define YYERROR_VERBOSE'), the expected token list in the
+  syntax error message can both contain invalid tokens and omit valid
+  tokens.
 
-*** Unrecognized variables are now an error not a warning.
+  The culprits for the above problems are %nonassoc, default
+  reductions in inconsistent states, and parser state merging.  Thus,
+  IELR and LALR suffer the most.  Canonical LR can suffer only if
+  %nonassoc is used or if default reductions are enabled for
+  inconsistent states.
 
-*** Multiple invocations for any variable is now an error not a warning.
+  LAC is a new mechanism within the parsing algorithm that solves
+  these problems for canonical LR, IELR, and LALR without sacrificing
+  %nonassoc, default reductions, or state merging.  When LAC is in
+  use, canonical LR and IELR behave almost exactly the same for both
+  syntactically acceptable and syntactically unacceptable input.
+  While LALR still does not support the full language-recognition
+  power of canonical LR and IELR, LAC at least enables LALR's syntax
+  error handling to correctly reflect LALR's language-recognition
+  power.
+
+  Currently, LAC is only supported for deterministic parsers in C.
+  You can enable LAC with the following directive:
+
+    %define parse.lac full
+
+  See the new section `LAC' in the Bison manual for additional
+  details including a few caveats.
 
-*** Can now be invoked via the command line.
+  LAC is an experimental feature.  More user feedback will help to
+  stabilize it.
+
+** %define improvements:
+
+*** Can now be invoked via the command line:
 
   Each of these command-line options
 
@@ -85,7 +127,7 @@ Bison News
   quietly override %define, but -D and --define do not.  For further
   details, see the section "Bison Options" in the Bison manual.
 
-*** Variables renamed.
+*** Variables renamed:
 
   The following %define variables
 
@@ -100,7 +142,7 @@ Bison News
   The old names are now deprecated but will be maintained indefinitely
   for backward compatibility.
 
-*** Values no longer need to be quoted in grammar file.
+*** Values no longer need to be quoted in grammar file:
 
   If a %define value is an identifier, it no longer needs to be placed
   within quotations marks.  For example,
@@ -111,47 +153,13 @@ Bison News
 
     %define api.push-pull push
 
-** Symbol names.
-
-  Consistently with directives (such as %error-verbose) and variables
-  (e.g. push-pull), symbol names may include dashes in any position,
-  similarly to periods and underscores.  This is GNU extension over
-  POSIX Yacc whose use is reported by -Wyacc, and rejected in Yacc
-  mode (--yacc).
-
-** YYFAIL now produces warnings and Java parsers no longer implement it.
-
-  YYFAIL has existed for many years as an undocumented feature of
-  deterministic parsers in C generated by Bison.  More recently, it was
-  a documented feature of Bison's experimental Java parsers.  As
-  promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
-  semantic action now produces a deprecation warning, and Java parsers
-  no longer implement YYFAIL at all.  For further details, including a
-  discussion of how to suppress C preprocessor warnings about YYFAIL
-  being unused, see the Bison 2.4.2 NEWS entry.
-
-** Temporary hack for adding a semicolon to the user action.
-
-  Previously, Bison appended a semicolon to every user action for
-  reductions when the output language defaulted to C (specifically, when
-  neither %yacc, %language, %skeleton, or equivalent command-line
-  options were specified).  This allowed actions such as
-
-    exp: exp "+" exp { $$ = $1 + $3 };
-
-  instead of
+*** Unrecognized variables are now errors not warnings.
 
-    exp: exp "+" exp { $$ = $1 + $3; };
+*** Multiple invocations for any variable is now an error not a warning.
 
-  As a first step in removing this misfeature, Bison now issues a
-  warning when it appends a semicolon.  Moreover, in cases where Bison
-  cannot easily determine whether a semicolon is needed (for example, an
-  action ending with a cpp directive or a braced compound initializer),
-  it no longer appends one.  Thus, the C compiler might now complain
-  about a missing semicolon where it did not before.  Future releases of
-  Bison will cease to append semicolons entirely.
+** Unrecognized %code qualifiers are now errors not warnings.
 
-** Character literals not of length one.
+** Character literals not of length one:
 
   Previously, Bison quietly converted all character literals to length
   one.  For example, without warning, Bison interpreted the operators in
@@ -162,52 +170,16 @@ 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 syntax error message fixes:
+  some future release, Bison will start reporting an error instead.
 
-  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.
+** Destructor calls fixed for lookaheads altered in semantic actions:
 
   Previously for deterministic parsers in C, if a user semantic action
   altered yychar, the parser in some cases used the old yychar value to
   determine which destructor to call for the lookahead upon a syntax
   error or upon parser return.  This bug has been fixed.
 
-** C++ parsers use YYRHSLOC
+** 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
@@ -242,13 +214,85 @@ Bison News
             }                                                              \
         while (false)
 
-** YYLLOC_DEFAULT in C++
+** 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.
 
+** YYFAIL now produces warnings and Java parsers no longer implement it:
+
+  YYFAIL has existed for many years as an undocumented feature of
+  deterministic parsers in C generated by Bison.  More recently, it was
+  a documented feature of Bison's experimental Java parsers.  As
+  promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
+  semantic action now produces a deprecation warning, and Java parsers
+  no longer implement YYFAIL at all.  For further details, including a
+  discussion of how to suppress C preprocessor warnings about YYFAIL
+  being unused, see the Bison 2.4.2 NEWS entry.
+
+** Temporary hack for adding a semicolon to the user action:
+
+  Previously, Bison appended a semicolon to every user action for
+  reductions when the output language defaulted to C (specifically, when
+  neither %yacc, %language, %skeleton, or equivalent command-line
+  options were specified).  This allowed actions such as
+
+    exp: exp "+" exp { $$ = $1 + $3 };
+
+  instead of
+
+    exp: exp "+" exp { $$ = $1 + $3; };
+
+  As a first step in removing this misfeature, Bison now issues a
+  warning when it appends a semicolon.  Moreover, in cases where Bison
+  cannot easily determine whether a semicolon is needed (for example, an
+  action ending with a cpp directive or a braced compound initializer),
+  it no longer appends one.  Thus, the C compiler might now complain
+  about a missing semicolon where it did not before.  Future releases of
+  Bison will cease to append semicolons entirely.
+
+** Verbose syntax error message fixes:
+
+  When %error-verbose or the obsolete `#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 a more complete fix requires LAC, described above:
+
+*** 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
+    invalid tokens 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.  Bison's new LAC implementation,
+    described above, eliminates this problem and the need for
+    canonical LR.  However, LAC is still experimental and is disabled
+    by default.
+
+** A location handling bug in the Java skeleton has been fixed.
+
 * Changes in version 2.4.3 (2010-08-05):
 
 ** Bison now obeys -Werror and --warnings=error for warnings about
@@ -1410,9 +1454,7 @@ End:
 
 -----
 
-Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
-2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
-Inc.
+Copyright (C) 1995-2011 Free Software Foundation, Inc.
 
 This file is part of Bison, the GNU Parser Generator.