Bison News
----------
-Changes in version 2.1a:
-
-* GLR, C++ LALR(1) parsers.
- These parser skeletons are now distributed with the same special
- license exception that the C LALR(1) parser skeleton has had since
- Bison 1.24. Hence the FSF imposes no copyright restriction on the
- output of Bison when it is generating such parsers.
+Changes in version 2.3+:
+
+* Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with `-y',
+ `--yacc', or `%yacc'), Bison no longer generates #define statements for
+ associating token numbers with token names. Removing the #define statements
+ helps to sanitize the global namespace during preprocessing, but POSIX Yacc
+ requires them. Bison still generates an enum for token names in all cases.
+
+* Handling of prologue blocks is now more consistent but potentially backward
+ incompatible.
+
+ As before, you declare prologue blocks in your grammar file with the
+ `%{ ... %}' syntax. To generate the pre-prologue, Bison concatenates all
+ prologue blocks that you've declared before any %union. If you've declared a
+ %union, Bison concatenates all prologue blocks that you've declared after it
+ to generate the post-prologue. (The new %before-definitions and
+ %after-definitions have a similar effect as %union on the prologues. See
+ below.)
+
+ Previous versions of Bison inserted the pre-prologue into both the header
+ file and the code file in all cases except for LALR(1) parsers in C. In the
+ latter case, Bison inserted it only into the code file. For parsers in C++,
+ the point of insertion was before any token definitions (which associate
+ token numbers with names). For parsers in C, the point of insertion was
+ after the token definitions.
+
+ Now, Bison never inserts the pre-prologue into the header file. In the code
+ file, it always inserts it before the token definitions.
+
+* Bison now provides the %before-definitions and %after-definitions directives.
+
+ For example, in your grammar file:
+
+ %{
+ /* A pre-prologue block. For Yacc portability, Bison no longer puts this
+ * in the header file. In the code file, Bison inserts it before any
+ * %before-definitions blocks. */
+ %}
+ %before-definitions {
+ /* Bison inserts this into both the header file and code file. In both
+ * files, the point of insertion is before any Bison-generated token,
+ * semantic type, location type, and class definitions. This is a good
+ * place to define %union dependencies, for example. */
+ }
+ %union {
+ /* With previous versions of Bison, the first %union in your grammar file
+ * separated the pre-prologue blocks from the post-prologue blocks. Now,
+ * the first %union, %before-definitions, or %after-definitions does
+ * that. */
+ }
+ %after-definitions {
+ /* If you want something in the header file and in the code file and it
+ * depends on any of the Bison-generated definitions in the header file,
+ * put it here. */
+ }
+ %{
+ /* A post-prologue block. If you want something in the code file but not
+ * in the header file and it depends on Bison-generated definitions, put
+ * it here. In the code file, Bison inserts it after any
+ * %after-definitions blocks. */
+ %}
+
+* The option `--report=look-ahead' has been changed to `--report=lookahead'.
+ The old spelling still works, but is not documented and may be removed
+ in a future release.
+
+Changes in version 2.3, 2006-06-05:
+
+* GLR grammars should now use `YYRECOVERING ()' instead of `YYRECOVERING',
+ for compatibility with LALR(1) grammars.
+
+* It is now documented that any definition of YYSTYPE or YYLTYPE should
+ be to a type name that does not contain parentheses or brackets.
+
+Changes in version 2.2, 2006-05-19:
+
+* The distribution terms for all Bison-generated parsers now permit
+ using the parsers in nonfree programs. Previously, this permission
+ was granted only for Bison-generated LALR(1) parsers in C.
+
+* %name-prefix changes the namespace name in C++ outputs.
+
+* The C++ parsers export their token_type.
+
+* Bison now allows multiple %union declarations, and concatenates
+ their contents together.
+
+* New warning: unused values
+ Right-hand side symbols whose values are not used are reported,
+ if the symbols have destructors. For instance:
+
+ exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
+ | 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); }
+ ;
+
+ 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; }
+ ;
+
+ 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.
+
+ exp: exp { push ($1); } '+' exp { push ($3); sum (); };
+
+ The warning is intended to help catching lost values and memory leaks.
+ If a value is ignored, its associated memory typically is not reclaimed.
+
+* %destructor vs. YYABORT, YYACCEPT, and YYERROR.
+ Destructors are now called when user code invokes YYABORT, YYACCEPT,
+ and YYERROR, for all objects on the stack, other than objects
+ corresponding to the right-hand side of the current rule.
* %expect, %expect-rr
Incorrect numbers of expected conflicts are now actual errors,
instead of warnings.
* GLR, YACC parsers.
- The %parse-params are available in the %destructor's (and the
- experimental %printer's) as per the documentation.
+ The %parse-params are available in the destructors (and the
+ experimental printers) as per the documentation.
* Bison now warns if it finds a stray `$' or `@' in an action.
* %require "VERSION"
- To specify that the grammar file depends on features implemented in
- Bison version VERSION or higher.
+ This specifies that the grammar file depends on features implemented
+ in Bison version VERSION or higher.
* lalr1.cc: The token and value types are now class members.
The tokens were defined as free form enums and cpp macros. YYSTYPE
for previous releases of Bison, and this one.
If you wish to update, then make sure older version of Bison will
- fail using `%require "2.1a"'.
+ fail using `%require "2.2"'.
* DJGPP support added.
-
+\f
Changes in version 2.1, 2005-09-16:
* The C++ lalr1.cc skeleton supports %lex-param.
a syntax error associated with '%token NUM "number"' they might
print 'syntax error, unexpected number' instead of 'syntax error,
unexpected "number"'.
-
+\f
Changes in version 2.0, 2004-12-25:
* Possibly-incompatible changes
This is a GNU extension.
- The option `--report=lookahead' was changed to `--report=look-ahead'.
- The old spelling still works, but is not documented and will be
- removed.
+ [However, this was changed back after 2.3.]
- Experimental %destructor support has been added to lalr1.cc.
produces additional information:
- itemset
complete the core item sets with their closure
- - lookahead [changed to `look-ahead' in 1.875e and later]
- explicitly associate look-ahead tokens to items
+ - lookahead [changed to `look-ahead' in 1.875e through 2.3, but changed back]
+ explicitly associate lookahead tokens to items
- solved
describe shift/reduce conflicts solving.
Bison used to systematically output this information on top of
-----
-Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005
-Free Software Foundation, Inc.
+Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
+2004, 2005, 2006 Free Software Foundation, Inc.
This file is part of Bison, the GNU Compiler Compiler.
projects / bison.git / blobdiff