]> git.saurik.com Git - bison.git/blobdiff - NEWS
style: space changes in the tests
[bison.git] / NEWS
diff --git a/NEWS b/NEWS
index 346c4da4be17a4481251f5c37c068ed350235235..5046a9b4a9923b813f0e0161a0d23e0a3fe8f100 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -2,16 +2,84 @@ GNU Bison NEWS
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
-** Incompatible changes
+** 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.25: warning: a ';' might be needed at the end of action code
+     exp: "number" { $$ = $1 }
+                             ^
+    foo.y:2.25:     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).
-  Support for yystype and yyltype (instead of YYSTYPE and YYLTYPE)
-  is removed (deprecated in Bison 1.875).
-  Support for YYPARSE_PARAM is removed (deprecated in Bison 1.875).
+  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 (glr.c)
+
+  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
 
-** Warnings
+  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).
+
+  Some error messages that reproduced excerpts of the grammar are now using
+  the caret information only.  For instance on:
+
+    %%
+    exp: 'a' | 'a';
+
+  Bison 2.7 reports:
+
+    in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
+    in.y:2.12-14: warning: rule useless in parser due to conflicts: exp: 'a' [-Wother]
+
+  Now bison reports:
+
+    in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
+    in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
+     exp: 'a' | 'a';
+                ^^^
+
+  and "bison -fno-caret" reports:
+
+    in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
+    in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
 
 *** Enhancements of the -Werror option
 
@@ -168,8 +236,160 @@ GNU Bison NEWS
 
     %param {arg1_type *arg1} {arg2_type *arg2}
 
+** 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".
+
+** 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
+
+** 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 developing 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:
+      "number"
+    | exp '+' "number"
+    | 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" '=' "number";
+
+  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" '=' "number";
+
+  The warning is:
+
+    warning: useless precedence and associativity for '=' [-Wprecedence]
+     %nonassoc '='
+               ^^^
+
+** Empty rules
+
+  With help from Joel E. Denny and Gabriel Rassoul.
+
+  Empty rules (i.e., with an empty right-hand side) can now be explicitly
+  marked by the new %empty directive.  Using %empty on a non-empty rule is
+  an error.  The new -Wempty-rule warning reports empty rules without
+  %empty.  On the following grammar:
+
+    %%
+    s: a b c;
+    a: ;
+    b: %empty;
+    c: 'a' %empty;
+
+  bison reports:
+
+    3.4-5: warning: empty rule without %empty [-Wempty-rule]
+     a: {}
+        ^^
+    5.8-13: error: %empty on non-empty rule
+     c: 'a' %empty {};
+            ^^^^^^
+
 ** 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".
@@ -195,52 +415,200 @@ GNU Bison NEWS
   used by the scanner, or rejecting invalid combinations from a
   factory invoked by the user actions).
 
-** Variable api.token.prefix
+*** %define api.value.type variant
 
-  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
+  This is based on a submission from Michiel De Wilde.  With help
+  from Théophile Ranquet.
 
-    %token FILE for ERROR
-    %define api.token.prefix "TOK_"
+  In this mode, complex C++ objects can be used as semantic values.  For
+  instance:
+
+    %token <::std::string> TEXT;
+    %token <int> NUMBER;
+    %token SEMICOLON ";"
+    %type <::std::string> item;
+    %type <::std::list<std::string>> list;
     %%
-    start: FILE for ERROR;
+    result:
+      list  { std::cout << $1 << std::endl; }
+    ;
+
+    list:
+      %empty        { /* Generates an empty string list. */ }
+    | list item ";" { std::swap ($$, $1); $$.push_back ($2); }
+    ;
+
+    item:
+      TEXT    { std::swap ($$, $1); }
+    | NUMBER  { $$ = string_cast ($1); }
+    ;
+
+*** %define api.token.constructor
+
+  When variants are enabled, Bison can generate functions to build the
+  tokens.  This guarantees that the token type (e.g., NUMBER) is consistent
+  with the semantic value (e.g., int):
+
+    parser::symbol_type yylex ()
+    {
+      parser::location_type loc = ...;
+      ...
+      return parser::make_TEXT ("Hello, world!", loc);
+      ...
+      return parser::make_NUMBER (42, loc);
+      ...
+      return parser::make_SEMICOLON (loc);
+      ...
+    }
 
-  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).
+* Noteworthy changes in release 2.7 (2012-12-12) [stable]
 
-** Renamed %define variables
+** Bug fixes
 
-  The following variables have been renamed for consistency.  Backward
-  compatibility is ensured, but upgrading is recommended.
+  Warnings about uninitialized yylloc in yyparse have been fixed.
 
-    lr.default-reductions      -> lr.default-reduction
-    lr.keep-unreachable-states -> lr.keep-unreachable-state
-    namespace                  -> api.namespace
+  Restored C90 compliance (yet no report was ever made).
 
-** Variable parse.error
+** Diagnostics are improved
 
-  This variable controls the verbosity of error messages.  The use of the
-  %error-verbose directive is deprecated in favor of "%define parse.error
-  verbose".
+  Contributed by Théophile Ranquet.
 
-** Semantic predicates
+*** Changes in the format of error messages
 
-  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.
+  This used to be the format of many error reports:
 
-** The directive %expect-rr is now an error in non GLR mode
+    input.y:2.7-12: %type redeclaration for exp
+    input.y:1.7-12: previous declaration
 
-  It used to be an error only if used in non GLR mode, _and_ if there are
-  reduce/reduce conflicts.
+  It is now:
 
-* Noteworthy changes in release ?.? (????-??-??) [?]
+    input.y:2.7-12: error: %type redeclaration for exp
+    input.y:1.7-12:     previous declaration
+
+*** New format for error reports: carets
+
+  Caret errors have been added to Bison:
+
+    input.y:2.7-12: error: %type redeclaration for exp
+     %type <sval> exp
+           ^^^^^^
+    input.y:1.7-12:     previous declaration
+     %type <ival> exp
+           ^^^^^^
+
+  or
+
+    input.y:3.20-23: error: ambiguous reference: '$exp'
+     exp: exp '+' exp { $exp = $1 + $3; };
+                        ^^^^
+    input.y:3.1-3:       refers to: $exp at $$
+     exp: exp '+' exp { $exp = $1 + $3; };
+     ^^^
+    input.y:3.6-8:       refers to: $exp at $1
+     exp: exp '+' exp { $exp = $1 + $3; };
+          ^^^
+    input.y:3.14-16:     refers to: $exp at $3
+     exp: exp '+' exp { $exp = $1 + $3; };
+                  ^^^
+
+  The default behavior for now is still not to display these unless
+  explicitly asked with -fcaret (or -fall). However, in a later release, it
+  will be made the default behavior (but may still be deactivated with
+  -fno-caret).
+
+** New value for %define variable: api.pure full
+
+  The %define variable api.pure requests a pure (reentrant) parser. However,
+  for historical reasons, using it in a location-tracking Yacc parser
+  resulted in a yyerror function that did not take a location as a
+  parameter. With this new value, the user may request a better pure parser,
+  where yyerror does take a location as a parameter (in location-tracking
+  parsers).
+
+  The use of "%define api.pure true" is deprecated in favor of this new
+  "%define api.pure full".
+
+** New %define variable: api.location.type (glr.cc, lalr1.cc, lalr1.java)
+
+  The %define variable api.location.type defines the name of the type to use
+  for locations.  When defined, Bison no longer generates the position.hh
+  and location.hh files, nor does the parser will include them: the user is
+  then responsible to define her type.
+
+  This can be used in programs with several parsers to factor their location
+  and position files: let one of them generate them, and the others just use
+  them.
+
+  This feature was actually introduced, but not documented, in Bison 2.5,
+  under the name "location_type" (which is maintained for backward
+  compatibility).
+
+  For consistency, lalr1.java's %define variables location_type and
+  position_type are deprecated in favor of api.location.type and
+  api.position.type.
+
+** Exception safety (lalr1.cc)
+
+  The parse function now catches exceptions, uses the %destructors to
+  release memory (the lookahead symbol and the symbols pushed on the stack)
+  before re-throwing the exception.
+
+  This feature is somewhat experimental.  User feedback would be
+  appreciated.
+
+** 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.
+
+  The reductions are now explicitly represented as transitions to other
+  diamond shaped nodes.
+
+  These changes are present in both --graph output and xml2dot.xsl XSLT
+  processing, with minor (documented) differences.
+
+** %language is no longer an experimental feature.
+
+  The introduction of this feature, in 2.4, was four years ago. The
+  --language option and the %language directive are no longer experimental.
+
+** Documentation
+
+  The sections about shift/reduce and reduce/reduce conflicts resolution
+  have been fixed and extended.
+
+  Although introduced more than four years ago, XML and Graphviz reports
+  were not properly documented.
+
+  The translation of mid-rule actions is now described.
+
+* Noteworthy changes in release 2.6.5 (2012-11-07) [stable]
+
+  We consider compiler warnings about Bison generated parsers to be bugs.
+  Rather than working around them in your own project, please consider
+  reporting them to us.
+
+** Bug fixes
+
+  Warnings about uninitialized yylval and/or yylloc for push parsers with a
+  pure interface have been fixed for GCC 4.0 up to 4.8, and Clang 2.9 to
+  3.2.
+
+  Other issues in the test suite have been addressed.
+
+  Null characters are correctly displayed in error messages.
+
+  When possible, yylloc is correctly initialized before calling yylex.  It
+  is no longer necessary to initialize it in the %initial-action.
+
+* Noteworthy changes in release 2.6.4 (2012-10-23) [stable]
+
+  Bison 2.6.3's --version was incorrect.  This release fixes this issue.
+
+* Noteworthy changes in release 2.6.3 (2012-10-22) [stable]
 
 ** Bug fixes
 
@@ -256,18 +624,6 @@ GNU Bison NEWS
 
   All the generated headers are self-contained.
 
-** Changes in the format of error messages
-
-  This used to be the format of many error reports:
-
-    foo.y:5.10-24: result type clash on merge function 'merge': <t3> != <t2>
-    foo.y:4.13-27: previous declaration
-
-  It is now:
-
-    foo.y:5.10-25: result type clash on merge function 'merge': <t3> != <t2>
-    foo.y:4.13-27:     previous declaration
-
 ** Header guards (yacc.c, glr.c, glr.cc)
 
   In order to avoid collisions, the header guards are now
@@ -279,15 +635,6 @@ GNU Bison NEWS
 
   will use YY_CALC_LIB_PARSE_H_INCLUDED as guard.
 
-** Exception safety (lalr1.cc)
-
-  The parse function now catches exceptions, uses the %destructors to
-  release memory (the lookahead symbol and the symbols pushed on the stack)
-  before re-throwing the exception.
-
-  This feature is somewhat experimental.  User feedback would be
-  appreciated.
-
 ** Fix compiler warnings in the generated parser (yacc.c, glr.c)
 
   The compilation of pure parsers (%define api.pure) can trigger GCC
@@ -305,25 +652,6 @@ GNU Bison NEWS
   "function declared 'noreturn' should not return") have also been
   addressed.
 
-** New %define variable: api.location.type (glr.cc, lalr1.cc, lalr1.java)
-
-  The %define variable api.location.type defines the name of the type to use
-  for locations.  When defined, Bison no longer generates the position.hh
-  and location.hh files, nor does the parser will include them: the user is
-  then responsible to define her type.
-
-  This can be used in programs with several parsers to factor their location
-  and position files: let one of them generate them, and the others just use
-  them.
-
-  This feature was actually introduced, but not documented, in Bison 2.5,
-  under the name "location_type" (which is maintained for backward
-  compatibility).
-
-  For consistency, lalr1.java's %define variables location_type and
-  position_type are deprecated in favor of api.location.type and
-  api.position.type.
-
 * Noteworthy changes in release 2.6.2 (2012-08-03) [stable]
 
 ** Bug fixes
@@ -380,7 +708,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.
@@ -642,6 +970,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):
 
@@ -672,7 +1001,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
@@ -1158,6 +1489,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
 
@@ -1171,6 +1503,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:
@@ -2147,7 +2480,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.
 
@@ -2182,7 +2515,12 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
  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 Wother nterm arg init
- LocalWords:  TOK calc yyo fval Wconflicts
+ LocalWords:  TOK calc yyo fval Wconflicts parsers yystackp yyval yynerrs
+ LocalWords:  Théophile Ranquet Santet fno fnone stype associativity Tolmer
+ LocalWords:  Wprecedence Rassoul Wempty Paolo Bonzini parser's Michiel loc
+ LocalWords:  redeclaration sval fcaret reentrant XSLT xsl Wmaybe yyvsp Tedi
+ LocalWords:  pragmas noreturn untyped Rozenman unexpanded Wojciech Polak
+ LocalWords:  Alexandre MERCHANTABILITY
 
 Local Variables:
 mode: outline