Bison News
----------
-Changes in version 2.3+:
+Changes in version 2.3a+ (????-??-??):
+
+* The -g and --graph options now output graphs in Graphviz DOT format,
+ not VCG format.
+
+* 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.
+
+ 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. For C/C++, it
+ replaces the traditional Yacc prologue, `%{CODE%}', for most purposes.
+ For Java, it inserts your CODE into the parser class. Compare with:
+
+ - `%{CODE%}' appearing after the first `%union {CODE}' in a C/C++
+ based 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. For C/C++, 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. For Java, this is the right place to write import
+ directives. Compare with:
+
+ - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
+ based 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. For C/C++, this directive inserts your CODE
+ both into the parser header file and into the parser code file after
+ Bison's required definitions. For Java, it inserts your CODE into the
+ parser java file after the parser class. Compare with:
+
+ - `%end-header {CODE}', which only Bison 2.3a supported.
+
+ 4. %code-top {CODE}
+
+ Occasionally for C/C++ it is desirable to insert code near the top of
+ the parser code file. For example:
+
+ %code-top {
+ #define _GNU_SOURCE
+ #include <stdio.h>
+ }
+
+ For Java, `%code-top {CODE}' is currently unused. Compare with:
+
+ - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
+ based 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.
+
+ Also see the new section `Prologue Alternatives' in the Bison manual.
+
+Changes in version 2.3a, 2006-09-13:
+
+* Instead of %union, you can define and use your own union type
+ YYSTYPE if your grammar contains at least one <type> tag.
+ Your YYSTYPE need not be a macro; it can be a typedef.
+ This change is for compatibility with other Yacc implementations,
+ and is required by POSIX.
* Locations columns and lines start at 1.
In accordance with the GNU Coding Standards and Emacs.
+* You may now declare per-type and default %destructor's and %printer's:
+
+ For example:
+
+ %union { char *string; }
+ %token <string> STRING1
+ %token <string> STRING2
+ %type <string> string1
+ %type <string> string2
+ %union { char character; }
+ %token <character> CHR
+ %type <character> chr
+ %destructor { free ($$); } %symbol-default
+ %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
+ %destructor { } <character>
+
+ guarantees that, when the parser discards any user-defined symbol that has a
+ semantic type tag other than `<character>', it passes its semantic value to
+ `free'. However, when the parser discards a `STRING1' or a `string1', it
+ also prints its line number to `stdout'. It performs only the second
+ `%destructor' in this case, so it invokes `free' only once.
+
* 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
`%{ ... %}' syntax. To generate the pre-prologue, Bison concatenates all
prologue blocks that you've declared before the first %union. To generate
the post-prologue, Bison concatenates all prologue blocks that you've
- declared after the first %union.
+ declared after the first %union.
Previous releases 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
projects / bison.git / blobdiff