X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/b2a0b7ca70f9490693d517d10c9c4a64c9fc1af0..17bd8a736a491f4867176b3885e39e74dc07f854:/NEWS

diff --git a/NEWS b/NEWS
index 749a2fa4..b1371ae7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,7 +1,121 @@
 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.
+
+* 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.
+
+  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.