]> git.saurik.com Git - bison.git/blobdiff - NEWS
skeletons: simplify the protections against "unused" warnings.
[bison.git] / NEWS
diff --git a/NEWS b/NEWS
index b9ce898c183d3b6ec27e103dee2a92509af4446a..a9922c0994f471eba079e6f0c496ca8f14bfe146 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -3,21 +3,113 @@ Bison News
 
 * Changes in version ?.? (????-??-??):
 
-** Java skeleton improvements:
+** Additional yylex/yyparse arguments
+
+  The new directive %param declare additional argument to both yylex
+  and yyparse.  The %lex-param, %parse-param, and %param directives
+  support one or more arguments.  Instead of
+
+      %lex-param   {arg1_type *arg1}
+      %lex-param   {arg2_type *arg2}
+      %parse-param {arg1_type *arg1}
+      %parse-param {arg2_type *arg2}
+
+  one may now declare
+
+      %param {arg1_type *arg1} {arg2_type *arg2}
+
+** Java skeleton improvements
 
   The constants for token names were moved to the Lexer interface.
   Also, it is possible to add code to the parser's constructors using
   "%code init" and "%define init_throws".
 
-* Changes in version 2.5 (????-??-??):
+** Variable api.tokens.prefix
+
+  The variable api.tokens.prefix changes the way tokens are identified in
+  the generated files.  This is especially useful to avoid collisions
+  with identifiers in the target language.  For instance
+
+      %token FILE for ERROR
+      %define api.tokens.prefix "TOK_"
+      %%
+      start: FILE for ERROR;
+
+  will generate the definition of the symbols TOK_FILE, TOK_for, and
+  TOK_ERROR in the generated sources.  In particular, the scanner must
+  use these prefixed token names, although the grammar itself still
+  uses the short names (as in the sample rule given above).
+
+** Variable api.namespace
+
+  The "namespace" variable is renamed "api.namespace".  Backward
+  compatibility is ensured, but upgrading is recommended.
+
+** Variable parse.error
+
+  The variable error controls the verbosity of error messages.  The
+  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.1 (????-??-??):
+
+** Some portability problems in the test suite have been fixed.
+
+** Minor improvements have been made to the manual.
+
+** YYBACKUP works as expected.
+
+* Changes in version 2.5 (2011-05-14):
+
+** 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
+  actions code.
+
+  Starting from this version, Bison can also accept named references.
+  When no ambiguity is possible, original symbol names may be used
+  as named references:
+
+    if_stmt : "if" cond_expr "then" then_stmt ';'
+    { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }
+
+  In the more common case, explicit names may be declared:
+
+    stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
+    { $res = mk_if_stmt($cond, $then, $else); }
+
+  Location information is also accessible using @name syntax.  When
+  accessing symbol names containing dots or dashes, explicit bracketing
+  ($[sym.1]) must be used.
+
+  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,
+  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,
   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
@@ -28,34 +120,81 @@ Bison News
   default.  You can specify the type of parser tables in the grammar
   file with these directives:
 
-    %define lr.type "LALR"
-    %define lr.type "IELR"
-    %define lr.type "canonical LR"
+    %define lr.type lalr
+    %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.
 
-** %define can now be invoked via the command line.
+** LAC (Lookahead Correction) for syntax error handling:
+
+  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.
+
+  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.
+
+  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.
+
+  LAC is an experimental feature.  More user feedback will help to
+  stabilize it.
 
-  Each of these bison command-line options
+** %define improvements:
 
-    -D NAME=VALUE
-    --define=NAME=VALUE
+*** Can now be invoked via the command line:
+
+  Each of these command-line options
+
+    -D NAME[=VALUE]
+    --define=NAME[=VALUE]
+
+    -F NAME[=VALUE]
+    --force-define=NAME[=VALUE]
 
   is equivalent to this grammar file declaration
 
-    %define NAME "VALUE"
+    %define NAME ["VALUE"]
 
-  for any NAME and VALUE.  Omitting `=VALUE' on the command line is
-  equivalent to omitting `"VALUE"' in the declaration.
+  except that the manner in which Bison processes multiple definitions
+  for the same NAME differs.  Most importantly, -F and --force-define
+  quietly override %define, but -D and --define do not.  For further
+  details, see the section `Bison Options' in the Bison manual.
 
-** %define variables renamed.
+*** Variables renamed:
 
   The following %define variables
 
@@ -70,7 +209,97 @@ Bison News
   The old names are now deprecated but will be maintained indefinitely
   for backward compatibility.
 
-** Temporary hack for adding a semicolon to the user action.
+*** Values no longer need to be quoted in the grammar file:
+
+  If a %define value is an identifier, it no longer needs to be placed
+  within quotations marks.  For example,
+
+    %define api.push-pull "push"
+
+  can be rewritten as
+
+    %define api.push-pull push
+
+*** Unrecognized variables are now errors not warnings.
+
+*** Multiple invocations for any variable is now an error not a warning.
+
+** Unrecognized %code qualifiers are now errors not warnings.
+
+** 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
+  the following grammar to be the same token:
+
+    exp: exp '++'
+       | exp '+' exp
+       ;
+
+  Bison now warns when a character literal is not of length one.  In
+  some future release, Bison will start reporting an error instead.
+
+** 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:
+
+  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.
+
+** 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
@@ -91,7 +320,219 @@ Bison News
   about a missing semicolon where it did not before.  Future releases of
   Bison will cease to append semicolons entirely.
 
-* Changes in version 2.4.2 (????-??-??):
+** 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.
+
+** Java skeleton fixes:
+
+*** A location handling bug has been fixed.
+
+*** The top element of each of the value stack and location stack is now
+    cleared when popped so that it can be garbage collected.
+
+*** Parser traces now print the top element of the stack.
+
+** -W/--warnings fixes:
+
+*** Bison now properly recognizes the `no-' versions of categories:
+
+  For example, given the following command line, Bison now enables all
+  warnings except warnings for incompatibilities with POSIX Yacc:
+
+    bison -Wall,no-yacc gram.y
+
+*** Bison now treats S/R and R/R conflicts like other warnings:
+
+  Previously, conflict reports were independent of Bison's normal
+  warning system.  Now, Bison recognizes the warning categories
+  `conflicts-sr' and `conflicts-rr'.  This change has important
+  consequences for the -W and --warnings command-line options.  For
+  example:
+
+    bison -Wno-conflicts-sr gram.y  # S/R conflicts not reported
+    bison -Wno-conflicts-rr gram.y  # R/R conflicts not reported
+    bison -Wnone            gram.y  # no conflicts are reported
+    bison -Werror           gram.y  # any conflict is an error
+
+  However, as before, if the %expect or %expect-rr directive is
+  specified, an unexpected number of conflicts is an error, and an
+  expected number of conflicts is not reported, so -W and --warning
+  then have no effect on the conflict report.
+
+*** The `none' category no longer disables a preceding `error':
+
+  For example, for the following command line, Bison now reports
+  errors instead of warnings for incompatibilities with POSIX Yacc:
+
+    bison -Werror,none,yacc gram.y
+
+*** The `none' category now disables all Bison warnings:
+
+  Previously, the `none' category disabled only Bison warnings for
+  which there existed a specific -W/--warning category.  However,
+  given the following command line, Bison is now guaranteed to
+  suppress all warnings:
+
+    bison -Wnone gram.y
+
+** Precedence directives can now assign token number 0:
+
+  Since Bison 2.3b, which restored the ability of precedence
+  directives to assign token numbers, doing so for token number 0 has
+  produced an assertion failure.  For example:
+
+    %left END 0
+
+  This bug has been fixed.
+
+* 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.
+
+  POSIX specifies that an error be reported for any identifier that does
+  not appear on the LHS of a grammar rule and that is not defined by
+  %token, %left, %right, or %nonassoc.  Bison 2.3b and later lost this
+  error report for the case when an identifier appears only after a
+  %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.
+
+** Warnings from gcc's -Wundef option about undefined YYENABLE_NLS,
+   YYLTYPE_IS_TRIVIAL, and __STRICT_ANSI__ in C/C++ parsers are now
+   avoided.
+
+** %code is now a permanent feature.
+
+  A traditional Yacc prologue directive is written in the form:
+
+    %{CODE%}
+
+  To provide a more flexible alternative, Bison 2.3b introduced the
+  %code directive with the following forms for C/C++:
+
+    %code          {CODE}
+    %code requires {CODE}
+    %code provides {CODE}
+    %code top      {CODE}
+
+  These forms are now considered permanent features of Bison.  See the
+  %code entries in the section "Bison Declaration Summary" in the Bison
+  manual for a summary of their functionality.  See the section
+  "Prologue Alternatives" for a detailed discussion including the
+  advantages of %code over the traditional Yacc prologue directive.
+
+  Bison's Java feature as a whole including its current usage of %code
+  is still considered experimental.
+
+** YYFAIL is deprecated and will eventually be removed.
+
+  YYFAIL has existed for many years as an undocumented feature of
+  deterministic parsers in C generated by Bison.  Previously, it was
+  documented for Bison's experimental Java parsers.  YYFAIL is no longer
+  documented for Java parsers and is formally deprecated in both cases.
+  Users are strongly encouraged to migrate to YYERROR, which is
+  specified by POSIX.
+
+  Like YYERROR, you can invoke YYFAIL from a semantic action in order to
+  induce a syntax error.  The most obvious difference from YYERROR is
+  that YYFAIL will automatically invoke yyerror to report the syntax
+  error so that you don't have to.  However, there are several other
+  subtle differences between YYERROR and YYFAIL, and YYFAIL suffers from
+  inherent flaws when %error-verbose or `#define YYERROR_VERBOSE' is
+  used.  For a more detailed discussion, see:
+
+    http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html
+
+  The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but
+  deterministic parsers in C will continue to implement it.  However,
+  because YYFAIL is already flawed, it seems futile to try to make new
+  Bison features compatible with it.  Thus, during parser generation,
+  Bison 2.5 will produce a warning whenever it discovers YYFAIL in a
+  rule action.  In a later release, YYFAIL will be disabled for
+  %error-verbose and `#define YYERROR_VERBOSE'.  Eventually, YYFAIL will
+  be removed altogether.
+
+  There exists at least one case where Bison 2.5's YYFAIL warning will
+  be a false positive.  Some projects add phony uses of YYFAIL and other
+  Bison-defined macros for the sole purpose of suppressing C
+  preprocessor warnings (from GCC cpp's -Wunused-macros, for example).
+  To avoid Bison's future warning, such YYFAIL uses can be moved to the
+  epilogue (that is, after the second `%%') in the Bison input file.  In
+  this release (2.4.2), Bison already generates its own code to suppress
+  C preprocessor warnings for YYFAIL, so projects can remove their own
+  phony uses of YYFAIL if compatibility with Bison releases prior to
+  2.4.2 is not necessary.
+
+** Internationalization.
+
+  Fix a regression introduced in Bison 2.4: Under some circumstances,
+  message translations were not installed although supported by the
+  host system.
 
 * Changes in version 2.4.1 (2008-12-11):
 
@@ -457,26 +898,26 @@ Bison News
   if the symbols have destructors.  For instance:
 
      exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
-       | exp "+" exp
-       ;
+        | exp "+" exp
+        ;
 
   will trigger a warning about $$ and $5 in the first rule, and $3 in
   the second ($1 is copied to $$ by the default rule).  This example
   most likely contains three errors, and could be rewritten as:
 
      exp: exp "?" exp ":" exp
-           { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
-       | exp "+" exp
-           { $$ = $1 ? $1 : $3; if ($1) free ($3); }
-       ;
+            { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
+        | exp "+" exp
+            { $$ = $1 ? $1 : $3; if ($1) free ($3); }
+        ;
 
   However, if the original actions were really intended, memory leaks
   and all, the warnings can be suppressed by letting Bison believe the
   values are used, e.g.:
 
      exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
-       | exp "+" exp         { $$ = $1; (void) $3; }
-       ;
+        | exp "+" exp         { $$ = $1; (void) $3; }
+        ;
 
   If there are mid-rule actions, the warning is issued if no action
   uses it.  The following triggers no warning: $1 and $3 are used.
@@ -720,16 +1161,16 @@ Bison News
   In agreement with POSIX and with other Yaccs, leaving a default
   action is valid when $$ is untyped, and $1 typed:
 
-       untyped: ... typed;
+        untyped: ... typed;
 
   but the converse remains an error:
 
-       typed: ... untyped;
+        typed: ... untyped;
 
 ** Values of mid-rule actions
   The following code:
 
-       foo: { ... } { $$ = $1; } ...
+        foo: { ... } { $$ = $1; } ...
 
   was incorrectly rejected: $1 is defined in the second mid-rule
   action, and is equal to the $$ of the first mid-rule action.
@@ -1140,8 +1581,7 @@ End:
 
 -----
 
-Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
-2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
+Copyright (C) 1995-2012 Free Software Foundation, Inc.
 
 This file is part of Bison, the GNU Parser Generator.