+Changes in version 2.3a+ (????-??-??):
+
+* The -g and --graph options now output graphs in Graphviz DOT format,
+ not VCG format.
+
+* An experimental directive %language specifies the language of the
+ generated parser, which can be C (the default) or C++. This
+ directive affects the skeleton used, and the names of the generated
+ files if the grammar file's name ends in ".y".
+
+* The grammar file may now specify the name of the parser header file using
+ %defines. For example:
+
+ %defines "parser.h"
+
+* The `=' that used to be required in the following declarations is now
+ deprecated:
+
+ %file-prefix "parser"
+ %name-prefix "c_"
+ %output "parser.c"
+
+* Revised warning: unset or unused mid-rule values
+
+ Since Bison 2.2, Bison has warned about mid-rule values that are set but not
+ used within any of the actions of the parent rule. For example, Bison warns
+ about unused $2 in:
+
+ exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };
+
+ Now, Bison also warns about mid-rule values that are used but not set. For
+ example, Bison warns about unset $$ in the mid-rule action in:
+
+ exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };
+
+ However, Bison now disables both of these warnings by default since they
+ sometimes prove to be false alarms in existing grammars employing the Yacc
+ constructs $0 or $-N (where N is some positive integer).
+
+ To enable these warnings, specify the flag `--warnings=midrule-values' or
+ `-W', which is a synonym for `--warnings=all'.
+
+* Bison now recognizes two separate kinds of default %destructor's and
+ %printer's:
+
+ 1. Place `<*>' in a %destructor/%printer symbol list to define a default
+ %destructor/%printer for all grammar symbols for which you have formally
+ declared semantic type tags.
+
+ 2. Place `<>' in a %destructor/%printer symbol list to define a default
+ %destructor/%printer for all grammar symbols without declared semantic
+ type tags.
+
+ Bison no longer supports the `%symbol-default' notation from Bison 2.3a.
+ `<*>' and `<>' combined achieve the same effect with one exception: Bison no
+ longer applies any %destructor to a mid-rule value if that mid-rule value is
+ not actually ever referenced using either $$ or $n in a semantic action.
+
+ The default %destructor's and %printer's are experimental. More user
+ feedback will help to determine whether they should become permanent
+ features.
+
+ See the section `Freeing Discarded Symbols' in the Bison manual for further
+ details.
+
+* The Yacc prologue alternatives from Bison 2.3a have been rewritten as the
+ following directives:
+
+ 1. %code {CODE}
+
+ Other than semantic actions, this is probably the most common place you
+ should write verbatim code for the parser implementation. It replaces
+ the traditional Yacc prologue, `%{CODE%}', for most purposes. Compare
+ with:
+
+ - `%{CODE%}' appearing after the first `%union {CODE}' in a grammar
+ file. While Bison will continue to support `%{CODE%}' for backward
+ compatibility, `%code {CODE}' is cleaner as its functionality does
+ not depend on its position in the grammar file relative to any
+ `%union {CODE}'. Specifically, `%code {CODE}' always inserts your
+ CODE into the parser code file after the usual contents of the
+ parser header file.
+ - `%after-header {CODE}', which only Bison 2.3a supported.
+
+ 2. %requires {CODE}
+
+ This is the right place to write dependency code for externally exposed
+ definitions required by Bison. Such exposed definitions are those
+ usually appearing in the parser header file. Thus, this is the right
+ place to define types referenced in `%union {CODE}' directives, and it
+ is the right place to override Bison's default YYSTYPE and YYLTYPE
+ definitions. Compare with:
+
+ - `%{CODE%}' appearing before the first `%union {CODE}' in a grammar
+ file. Unlike `%{CODE%}', `%requires {CODE}' inserts your CODE both
+ into the parser code file and into the parser header file since
+ Bison's required definitions should depend on it in both places.
+ - `%start-header {CODE}', which only Bison 2.3a supported.
+
+ 3. %provides {CODE}
+
+ This is the right place to write additional definitions you would like
+ Bison to expose externally. That is, this directive inserts your CODE
+ both into the parser header file and into the parser code file after
+ Bison's required definitions. Compare with:
+
+ - `%end-header {CODE}', which only Bison 2.3a supported.
+
+ 4. %code-top {CODE}
+
+ Occasionally it is desirable to insert code near the top of the parser
+ code file. For example:
+
+ %code-top {
+ #define _GNU_SOURCE
+ #include <stdio.h>
+ }
+
+ Compare with:
+
+ - `%{CODE%}' appearing before the first `%union {CODE}' in a grammar
+ file. `%code-top {CODE}' is cleaner as its functionality does not
+ depend on its position in the grammar file relative to any
+ `%union {CODE}'.
+ - `%before-header {CODE}', which only Bison 2.3a supported.
+
+ If you have multiple occurrences of any one of the above four directives,
+ Bison will concatenate the contents in the order they appear in the grammar
+ file.
+
+ The prologue alternatives are experimental. More user feedback will help to
+ determine whether they should become permanent features.
+
+ Also see the new section `Prologue Alternatives' in the Bison manual.
+
+Changes in version 2.3a, 2006-09-13:
projects / bison.git / blobdiff