]> git.saurik.com Git - bison.git/blobdiff - NEWS
symlist: use the right stream
[bison.git] / NEWS
diff --git a/NEWS b/NEWS
index d16ac50b8b69b4edbca9b299e16bb6424ef5733a..20c3100fce736197887511d750ad734f1b499794 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -2,12 +2,384 @@ GNU Bison NEWS
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+** WARNING: Future backward-incompatibilities!
+
+  Bison will stop adding a semicolon at the end of the actions (as announced
+  in the release 2.5):
+
+    foo.y:2.22: warning: a ';' might be needed at the end of action code
+     exp: "num" { $$ = $1 }
+                          ^
+    foo.y:2.22:     future versions of Bison will not add the ';'
+
+  Like other GNU packages, Bison will start using some of the C99 features
+  for its own code, especially the definition of variables after statements.
+  The generated C parsers still aim at C90.
+
+** Backward incompatible changes
+
+*** Obsolete features
+
+  Support for YYFAIL is removed (deprecated in Bison 2.4.2): use YYERROR.
+
+  Support for yystype and yyltype is removed (deprecated in Bison 1.875):
+  use YYSTYPE and YYLTYPE.
+
+  Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
+  1.875): use %lex-param, %parse-param, or %param.
+
+** Bug fixes
+
+*** The epilogue is no longer affected by internal #defines
+
+  The glr.c skeleton uses defines such as #define yylval (yystackp->yyval) in
+  generated code.  These weren't properly undefined before the inclusion of
+  the user epilogue, so functions such as the following were butchered by the
+  preprocessor expansion:
+
+    int yylex (YYSTYPE *yylval);
+
+  This is has been fixed: yylval, yynerrs, yychar, and yylloc are now valid
+  identifiers for user-provided variables.
+
+*** stdio.h is no longer needed when locations are enabled (yacc.c)
+
+  Changes in Bison 2.7 introduced a dependency on FILE and fprintf when
+  locations are enabled.  This is fixed.
+
+** Diagnostics reported by Bison
+
+  Most of these features were contributed by Théophile Ranquet and Victor
+  Santet.
+
+*** Carets
+
+  Version 2.7 introduced caret errors, for a prettier output.  These are now
+  activated by default.  The old format can still be used by invoking Bison
+  with -fno-caret (or -fnone).
+
+*** Enhancements of the -Werror option
+
+  The -Werror=CATEGORY option is now recognized, and will treat specified
+  warnings as errors. The warnings need not have been explicitly activated
+  using the -W option, this is similar to what GCC 4.7 does.
+
+  For example, given the following command line, Bison will treat both
+  warnings related to POSIX Yacc incompatibilities and S/R conflicts as
+  errors (and only those):
+
+    $ bison -Werror=yacc,error=conflicts-sr input.y
+
+  If no categories are specified, -Werror will make all active warnings into
+  errors. For example, the following line does the same the previous example:
+
+    $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y
+
+  (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)
+
+  Note that the categories in this -Werror option may not be prefixed with
+  "no-". However, -Wno-error[=CATEGORY] is valid.
+
+  Note that -y enables -Werror=yacc. Therefore it is now possible to require
+  Yacc-like behavior (e.g., always generate y.tab.c), but to report
+  incompatibilities as warnings: "-y -Wno-error=yacc".
+
+*** The display of warnings is now richer
+
+  The option that controls a given warning is now displayed:
+
+    foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
+
+  In the case of warnings treated as errors, the prefix is changed from
+  "warning: " to "error: ", and the suffix is displayed, in a manner similar
+  to GCC, as [-Werror=CATEGORY].
+
+  For instance, where the previous version of Bison would report (and exit
+  with failure):
+
+    bison: warnings being treated as errors
+    input.y:1.1: warning: stray ',' treated as white space
+
+  it now reports:
+
+    input.y:1.1: error: stray ',' treated as white space [-Werror=other]
+
+*** Deprecated constructs
+
+  The new 'deprecated' warning category flags obsolete constructs whose
+  support will be discontinued.  It is enabled by default.  These warnings
+  used to be reported as 'other' warnings.
+
+*** Useless semantic types
+
+  Bison now warns about useless (uninhabited) semantic types.  Since
+  semantic types are not declared to Bison (they are defined in the opaque
+  %union structure), it is %printer/%destructor directives about useless
+  types that trigger the warning:
+
+    %token <type1> term
+    %type  <type2> nterm
+    %printer    {} <type1> <type3>
+    %destructor {} <type2> <type4>
+    %%
+    nterm: term { $$ = $1; };
+
+    3.28-34: warning: type <type3> is used, but is not associated to any symbol
+    4.28-34: warning: type <type4> is used, but is not associated to any symbol
+
+*** Undefined but unused symbols
+
+  Bison used to raise an error for undefined symbols that are not used in
+  the grammar.  This is now only a warning.
+
+    %printer    {} symbol1
+    %destructor {} symbol2
+    %type <type>   symbol3
+    %%
+    exp: "a";
+
+*** Useless destructors or printers
+
+  Bison now warns about useless destructors or printers.  In the following
+  example, the printer for <type1>, and the destructor for <type2> are
+  useless: all symbols of <type1> (token1) already have a printer, and all
+  symbols of type <type2> (token2) already have a destructor.
+
+    %token <type1> token1
+           <type2> token2
+           <type3> token3
+           <type4> token4
+    %printer    {} token1 <type1> <type3>
+    %destructor {} token2 <type2> <type4>
+
+*** Conflicts
+
+  The warnings and error messages about shift/reduce and reduce/reduce
+  conflicts have been normalized.  For instance on the following foo.y file:
+
+    %glr-parser
+    %%
+    exp: exp '+' exp | '0' | '0';
+
+  compare the previous version of bison:
+
+    $ bison foo.y
+    foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
+    $ bison -Werror foo.y
+    bison: warnings being treated as errors
+    foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
+
+  with the new behavior:
+
+    $ bison foo.y
+    foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
+    foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
+    $ bison -Werror foo.y
+    foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
+    foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]
+
+  When %expect or %expect-rr is used, such as with bar.y:
+
+    %expect 0
+    %glr-parser
+    %%
+    exp: exp '+' exp | '0' | '0';
+
+  Former behavior:
+
+    $ bison bar.y
+    bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
+    bar.y: expected 0 shift/reduce conflicts
+    bar.y: expected 0 reduce/reduce conflicts
+
+  New one:
+
+    $ bison bar.y
+    bar.y: error: shift/reduce conflicts: 1 found, 0 expected
+    bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
+
+** Additional yylex/yyparse arguments
+
+  The new directive %param declares additional arguments 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
+
+  Contributed by Paolo Bonzini.
+
+  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".
+
+** C++ skeletons improvements
+
+*** The parser header is no longer mandatory (lalr1.cc, glr.cc)
+
+  Using %defines is now optional.  Without it, the needed support classes
+  are defined in the generated parser, instead of additional files (such as
+  location.hh, position.hh and stack.hh).
+
+*** Locations are no longer mandatory (lalr1.cc, glr.cc)
+
+  Both lalr1.cc and glr.cc no longer require %location.
+
+*** syntax_error exception (lalr1.cc)
+
+  The C++ parser features a syntax_error exception, which can be
+  thrown from the scanner or from user rules to raise syntax errors.
+  This facilitates reporting errors caught in sub-functions (e.g.,
+  rejecting too large integral literals from a conversion function
+  used by the scanner, or rejecting invalid combinations from a
+  factory invoked by the user actions).
+
+** Renamed %define variables
+
+  The following variables have been renamed for consistency.  Backward
+  compatibility is ensured, but upgrading is recommended.
+
+    lr.default-reductions      -> lr.default-reduction
+    lr.keep-unreachable-states -> lr.keep-unreachable-state
+    namespace                  -> api.namespace
+    stype                      -> api.value.type
+
+** Variable api.token.prefix
+
+  The variable api.token.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.token.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 parse.error
+
+  This variable controls the verbosity of error messages.  The use of the
+  %error-verbose directive is deprecated in favor of "%define parse.error
+  verbose".
+
+** Semantic predicates
+
+  Contributed by Paul Hilfinger.
+
+  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 run-time
+  expressions.
+
+** The directive %expect-rr is now an error in non GLR mode
+
+  It used to be an error only if used in non GLR mode, _and_ if there are
+  reduce/reduce conflicts.
+
+** Token numbering has changed to preserve the user-defined order
+
+  When declaring %token A B, the numbering for A is inferior to B. Up to now,
+  when declaring associativity at the same time, with %left (or %right,
+  %precedence, %nonassoc), B was inferior to A.
+
+** Useless precedence and associativity
+
+  Contributed by Valentin Tolmer.
+
+  When developping and maintaining a grammar, useless associativity and
+  precedence directives are common.  They can be a nuisance: new ambiguities
+  arising are sometimes masked because their conflicts are resolved due to
+  the extra precedence or associativity information.  Furthermore, it can
+  hinder the comprehension of a new grammar: one will wonder about the role
+  of a precedence, where in fact it is useless.  The following changes aim
+  at detecting and reporting these extra directives.
+
+*** Precedence warning category
+
+  A new category of warning, -Wprecedence, was introduced. It flags the
+  useless precedence and associativity directives.
+
+*** Useless associativity
+
+  Bison now warns about symbols with a declared associativity that is never
+  used to resolve conflicts.  In that case, using %precedence is sufficient;
+  the parsing tables will remain unchanged.  Solving these warnings may raise
+  useless precedence warnings, as the symbols no longer have associativity.
+  For example:
+
+    %left '+'
+    %left '*'
+    %%
+    exp:
+      "num"
+    | exp '+' "num"
+    | exp '*' exp
+    ;
+
+  will produce a
+
+    warning: useless associativity for '+', use %precedence [-Wprecedence]
+     %left '+'
+           ^^^
+
+*** Useless precedence
+
+  Bison now warns about symbols with a declared precedence and no declared
+  associativity (i.e., declared with %precedence), and whose precedence is
+  never used.  In that case, the symbol can be safely declared with %token
+  instead, without modifying the parsing tables.  For example:
+
+    %precedence '='
+    %%
+    exp: "var" '=' "num";
+
+  will produce a
+
+    warning: useless precedence for '=' [-Wprecedence]
+     %precedence '='
+                 ^^^
+
+*** Useless precedence and associativity
+
+  In case of both useless precedence and associativity, the issue is flagged
+  as follows:
+
+    %nonassoc '='
+    %%
+    exp: "var" '=' "num";
+
+  The warning is:
+
+    warning: useless precedence and associativity for '=' [-Wprecedence]
+     %nonassoc '='
+               ^^^
+
+* Noteworthy changes in release 2.7 (2012-12-12) [stable]
+
 ** Bug fixes
 
   Warnings about uninitialized yylloc in yyparse have been fixed.
 
+  Restored C90 compliance (yet no report was ever made).
+
 ** Diagnostics are improved
 
+  Contributed by Théophile Ranquet.
+
 *** Changes in the format of error messages
 
   This used to be the format of many error reports:
@@ -93,6 +465,8 @@ GNU Bison NEWS
 
 ** Graph improvements in DOT and XSLT
 
+  Contributed by Théophile Ranquet.
+
   The graphical presentation of the states is more readable: their shape is
   now rectangular, the state number is clearly displayed, and the items are
   numbered and left-justified.
@@ -203,7 +577,7 @@ GNU Bison NEWS
 
 * Noteworthy changes in release 2.6.1 (2012-07-30) [stable]
 
 Bison no longer executes user-specified M4 code when processing a grammar.
+ Bison no longer executes user-specified M4 code when processing a grammar.
 
 ** Future Changes
 
@@ -241,7 +615,7 @@ GNU Bison NEWS
 
 * Noteworthy changes in release 2.6 (2012-07-19) [stable]
 
-** Future Changes
+** Future changes
 
   The next major release of Bison will drop support for the following
   deprecated features.  Please report disagreements to bug-bison@gnu.org.
@@ -503,6 +877,7 @@ GNU Bison NEWS
 
   These features are experimental in this version.  More user feedback
   will help to stabilize them.
+  Contributed by Alex Rozenman.
 
 ** IELR(1) and canonical LR(1):
 
@@ -533,7 +908,9 @@ GNU Bison NEWS
   These features are experimental.  More user feedback will help to
   stabilize them.
 
-** LAC (Lookahead Correction) for syntax error handling:
+** LAC (Lookahead Correction) for syntax error handling
+
+  Contributed by Joel E. Denny.
 
   Canonical LR, IELR, and LALR can suffer from a couple of problems
   upon encountering a syntax error.  First, the parser might perform
@@ -1019,6 +1396,7 @@ GNU Bison NEWS
 
   The current Java interface is experimental and may evolve.  More user
   feedback will help to stabilize it.
+  Contributed by Paolo Bonzini.
 
 ** %language
 
@@ -1032,6 +1410,7 @@ GNU Bison NEWS
   Bison can now generate an XML report of the LALR(1) automaton using the new
   "--xml" option.  The current XML schema is experimental and may evolve.  More
   user feedback will help to stabilize it.
+  Contributed by Wojciech Polak.
 
 ** The grammar file may now specify the name of the parser header file using
   %defines.  For example:
@@ -2008,7 +2387,7 @@ Output file does not redefine const for C++.
 
 -----
 
-Copyright (C) 1995-2012 Free Software Foundation, Inc.
+Copyright (C) 1995-2013 Free Software Foundation, Inc.
 
 This file is part of Bison, the GNU Parser Generator.
 
@@ -2042,8 +2421,8 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
  LocalWords:  namespaces strerror const autoconfiguration Dconst Autoconf's FDL
  LocalWords:  Automake TMPDIR LESSEQ ylwrap endif yydebug YYTOKEN YYLSP ival hh
  LocalWords:  extern YYTOKENTYPE TOKENTYPE yytokentype tokentype STYPE lval pdf
- LocalWords:  lang yyoutput dvi html ps POSIX lvalp llocp calc yyo fval Wmaybe
- LocalWords:  yyvsp pragmas noreturn java's
+ LocalWords:  lang yyoutput dvi html ps POSIX lvalp llocp Wother nterm arg init
+ LocalWords:  TOK calc yyo fval Wconflicts
 
 Local Variables:
 mode: outline