-Changes in version 2.3a+ (????-??-??):
-
-* The -g and --graph options now output graphs in Graphviz DOT format,
- not VCG format.
-
-* 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.
-
-Changes in version 2.3a, 2006-09-13:
-
-* Instead of %union, you can define and use your own union type
+* Changes in version 2.4.2 (????-??-??):
+
+* Changes in version 2.4.1 (2008-12-11):
+
+** In the GLR defines file, unexpanded M4 macros in the yylval and yylloc
+ declarations have been fixed.
+
+** 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):
+
+** %language is an experimental feature.
+
+ We first introduced this feature in test release 2.3b as a cleaner
+ alternative to %skeleton. Since then, we have discussed the possibility of
+ modifying its effect on Bison's output file names. Thus, in this release,
+ we consider %language to be an experimental feature that will likely evolve
+ in future releases.
+
+** Forward compatibility with GNU M4 has been improved.
+
+** Several bugs in the C++ skeleton and the experimental Java skeleton have been
+ fixed.
+
+* Changes in version 2.3b (2008-05-27):
+
+** The quotes around NAME that used to be required in the following directive
+ are now deprecated:
+
+ %define NAME "VALUE"
+
+** The directive `%pure-parser' is now deprecated in favor of:
+
+ %define api.pure
+
+ which has the same effect except that Bison is more careful to warn about
+ unreasonable usage in the latter case.
+
+** Push Parsing
+
+ Bison can now generate an LALR(1) parser in C with a push interface. That
+ is, instead of invoking `yyparse', which pulls tokens from `yylex', you can
+ push one token at a time to the parser using `yypush_parse', which will
+ return to the caller after processing each token. By default, the push
+ interface is disabled. Either of the following directives will enable it:
+
+ %define api.push_pull "push" // Just push; does not require yylex.
+ %define api.push_pull "both" // Push and pull; requires yylex.
+
+ See the new section `A Push Parser' in the Bison manual for details.
+
+ The current push parsing interface is experimental and may evolve. More user
+ feedback will help to stabilize it.
+
+** The -g and --graph options now output graphs in Graphviz DOT format,
+ not VCG format. Like --graph, -g now also takes an optional FILE argument
+ and thus cannot be bundled with other short options.
+
+** Java
+
+ Bison can now generate an LALR(1) parser in Java. The skeleton is
+ `data/lalr1.java'. Consider using the new %language directive instead of
+ %skeleton to select it.
+
+ See the new section `Java Parsers' in the Bison manual for details.
+
+ The current Java interface is experimental and may evolve. More user
+ feedback will help to stabilize it.
+
+** %language
+
+ This new directive specifies the programming language of the generated
+ parser, which can be C (the default), C++, or Java. Besides the skeleton
+ that Bison uses, the directive affects the names of the generated files if
+ the grammar file's name ends in ".y".
+
+** XML Automaton Report
+
+ Bison can now generate an XML report of the LALR(1) automaton using the new
+ `--xml' option. The current XML schema is experimental and may evolve. More
+ user feedback will help to stabilize it.
+
+** The grammar file may now specify the name of the parser header file using
+ %defines. For example:
+
+ %defines "parser.h"
+
+** When reporting useless rules, useless nonterminals, and unused terminals,
+ Bison now employs the terms "useless in grammar" instead of "useless",
+ "useless in parser" instead of "never reduced", and "unused in grammar"
+ instead of "unused".
+
+** Unreachable State Removal
+
+ Previously, Bison sometimes generated parser tables containing unreachable
+ states. A state can become unreachable during conflict resolution if Bison
+ disables a shift action leading to it from a predecessor state. Bison now:
+
+ 1. Removes unreachable states.
+
+ 2. Does not report any conflicts that appeared in unreachable states.
+ WARNING: As a result, you may need to update %expect and %expect-rr
+ directives in existing grammar files.
+
+ 3. For any rule used only in such states, Bison now reports the rule as
+ "useless in parser due to conflicts".
+
+ This feature can be disabled with the following directive:
+
+ %define lr.keep_unreachable_states
+
+ See the %define entry in the `Bison Declaration Summary' in the Bison manual
+ for further discussion.
+
+** Lookahead Set Correction in the `.output' Report
+
+ When instructed to generate a `.output' file including lookahead sets
+ (using `--report=lookahead', for example), Bison now prints each reduction's
+ lookahead set only next to the associated state's one item that (1) is
+ associated with the same rule as the reduction and (2) has its dot at the end
+ of its RHS. Previously, Bison also erroneously printed the lookahead set
+ next to all of the state's other items associated with the same rule. This
+ bug affected only the `.output' file and not the generated parser source
+ code.
+
+** --report-file=FILE is a new option to override the default `.output' file
+ name.
+
+** The `=' that used to be required in the following directives is now
+ deprecated:
+
+ %file-prefix "parser"
+ %name-prefix "c_"
+ %output "parser.c"
+
+** An Alternative to `%{...%}' -- `%code QUALIFIER {CODE}'
+
+ Bison 2.3a provided a new set of directives as a more flexible alternative to
+ the traditional Yacc prologue blocks. Those have now been consolidated into
+ a single %code directive with an optional qualifier field, which identifies
+ the purpose of the code and thus the location(s) where Bison should generate
+ it:
+
+ 1. `%code {CODE}' replaces `%after-header {CODE}'
+ 2. `%code requires {CODE}' replaces `%start-header {CODE}'
+ 3. `%code provides {CODE}' replaces `%end-header {CODE}'
+ 4. `%code top {CODE}' replaces `%before-header {CODE}'
+
+ See the %code entries in section `Bison Declaration Summary' in the Bison
+ manual for a summary of the new functionality. See the new section `Prologue
+ Alternatives' for a detailed discussion including the advantages of %code
+ over the traditional Yacc prologues.
+
+ The prologue alternatives are experimental. More user feedback will help to
+ determine whether they should become permanent features.
+
+** 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 option `--warnings=midrule-values' or
+ `-W', which is a synonym for `--warnings=all'.
+
+** Default %destructor or %printer with `<*>' or `<>'
+
+ 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.
+
+** %left, %right, and %nonassoc can now declare token numbers. This is required
+ by POSIX. However, see the end of section `Operator Precedence' in the Bison
+ manual for a caveat concerning the treatment of literal strings.
+
+** The nonfunctional --no-parser, -n, and %no-parser options have been
+ completely removed from Bison.
+
+* Changes in version 2.3a, 2006-09-13:
+
+** Instead of %union, you can define and use your own union type
projects / bison.git / blobdiff