* Changes in version ?.? (????-??-??):
+** 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 (????-??-??):
+
+** IELR(1) and Canonical LR(1) Support
+
+ 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,
+ 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
+ significantly reduce the complexity of developing of a grammar.
+
+ Bison can now generate IELR(1) and canonical LR(1) parser tables in
+ place of its traditional LALR(1) parser tables, which remain the
+ 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"
+
+ 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.
+
+ These features are experimental. More user feedback will help to
+ stabilize them.
+
+** %define can now be invoked via the command line.
+
+ Each of these bison command-line options
+
+ -D NAME=VALUE
+ --define=NAME=VALUE
+
+ is equivalent to this grammar file declaration
+
+ %define NAME "VALUE"
+
+ for any NAME and VALUE. Omitting `=VALUE' on the command line is
+ equivalent to omitting `"VALUE"' in the declaration.
+
+** 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.
+
* Changes in version 2.4.2 (????-??-??):
* Changes in version 2.4.1 (2008-12-11):
-* Java skeleton improvements:
+** In the GLR defines file, unexpanded M4 macros in the yylval and yylloc
+ declarations have been fixed.
- 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".
+** Temporary hack for adding a semicolon to the user action.
+
+ Bison used to prepend a trailing semicolon at the end of the user
+ action for reductions. This allowed actions such as
+
+ exp: exp "+" exp { $$ = $1 + $3 };
+
+ instead of
+
+ exp: exp "+" exp { $$ = $1 + $3; };
+
+ Some grammars still depend on this `feature'. Bison 2.4.1 restores
+ the previous behavior in the case of C output (specifically, when
+ neither %language or %skeleton or equivalent command-line options
+ are used) to leave more time for grammars depending on the old
+ behavior to be adjusted. Future releases of Bison will disable this
+ feature.
+
+** A few minor improvements to the Bison manual.
* Changes in version 2.4 (2008-11-02):
projects / bison.git / blobdiff