+* Changes in version 2.5 (????-??-??):
+
+** Named References Support
+
+ 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) 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.
+
+** Unrecognized %code qualifiers are now an error not a warning.
+
+** %define improvements.
+
+*** Unrecognized variables are now an error not a warning.
+
+*** Multiple invocations for any variable is now an error not a warning.
+
+*** 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"]
+
+ 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.
+
+*** Variables renamed.
+
+ The following %define variables
+
+ api.push_pull
+ lr.keep_unreachable_states
+
+ have been renamed to
+
+ api.push-pull
+ lr.keep-unreachable-states
+
+ The old names are now deprecated but will be maintained indefinitely
+ for backward compatibility.
+
+*** Values no longer need to be quoted in 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
+
+** Symbol names.
+
+ Consistently with directives (such as %error-verbose) and variables
+ (e.g. push-pull), symbol names may include dashes in any position,
+ similarly to periods and underscores. This is GNU extension over
+ POSIX Yacc whose use is reported by -Wyacc, and rejected in Yacc
+ mode (--yacc).
+
+** 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.
+
+** `%prec IDENTIFIER' requires IDENTIFIER to be defined separately.
+
+ As promised in Bison 2.4.2's NEWS entry, it is now an error if a token
+ that appears after a %prec directive is not defined by %token, %left,
+ %right, or %nonassoc. This is required by POSIX.
+
+** 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.
+
+** 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 report an error instead.
+
+** Verbose error messages fixed for nonassociative tokens.
+
+ When %error-verbose is specified, syntax error messages produced by
+ the generated parser include the unexpected token as well as a list of
+ expected tokens. Previously, this list erroneously included tokens
+ that would actually induce a syntax error because conflicts for them
+ were resolved with %nonassoc. Such tokens are now properly omitted
+ from the list.
+
+** 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.
+