Also, it is possible to add code to the parser's constructors using
"%code init" and "%define init_throws".
+** C++ skeleton improvements
+
+ 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).
+
** Variable api.tokens.prefix
The variable api.tokens.prefix changes the way tokens are identified in
allow the programmer to prune possible parses based on the values of
runtime expressions.
-* Changes in version 2.5 (????-??-??):
+* Changes in version 2.5.1 (????-??-??):
+
+** Some portability problems in the test suite have been fixed.
+
+** Minor improvements have been made to the manual.
+
+** YYBACKUP works as expected.
+
+* Changes in version 2.5 (2011-05-14):
** Grammar symbol names can now contain non-initial dashes:
bison -Werror,none,yacc gram.y
-*** The `none' category now disables all Bison warnings.
+*** The `none' category now disables all Bison warnings:
Previously, the `none' category disabled only Bison warnings for
which there existed a specific -W/--warning category. However,
bison -Wnone gram.y
+** Precedence directives can now assign token number 0:
+
+ Since Bison 2.3b, which restored the ability of precedence
+ directives to assign token numbers, doing so for token number 0 has
+ produced an assertion failure. For example:
+
+ %left END 0
+
+ This bug has been fixed.
+
* Changes in version 2.4.3 (2010-08-05):
** Bison now obeys -Werror and --warnings=error for warnings about
if the symbols have destructors. For instance:
exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
- | exp "+" exp
- ;
+ | 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); }
- ;
+ { $$ = $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; }
- ;
+ | 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.
In agreement with POSIX and with other Yaccs, leaving a default
action is valid when $$ is untyped, and $1 typed:
- untyped: ... typed;
+ untyped: ... typed;
but the converse remains an error:
- typed: ... untyped;
+ typed: ... untyped;
** Values of mid-rule actions
The following code:
- foo: { ... } { $$ = $1; } ...
+ foo: { ... } { $$ = $1; } ...
was incorrectly rejected: $1 is defined in the second mid-rule
action, and is equal to the $$ of the first mid-rule action.
-----
-Copyright (C) 1995-2011 Free Software Foundation, Inc.
+Copyright (C) 1995-2012 Free Software Foundation, Inc.
This file is part of Bison, the GNU Parser Generator.