X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/6c7022f7d35ef6e35d52b2ff8e7ab674800f70c1..90b89dadb24edfe00ed163ddb9407a48d6f4a9ac:/NEWS

diff --git a/NEWS b/NEWS
index a48ef713..3816fdd5 100644
--- a/NEWS
+++ b/NEWS
@@ -4,14 +4,6 @@ GNU Bison NEWS
 
 ** WARNING: Future backward-incompatibilities!
 
-  Bison will stop adding a semicolon at the end of the actions (as announced
-  in the release 2.5):
-
-    foo.y:2.25: warning: a ';' might be needed at the end of action code
-     exp: "number" { $$ = $1 }
-                             ^
-    foo.y:2.25:     future versions of Bison will not add the ';'
-
   Like other GNU packages, Bison will start using some of the C99 features
   for its own code, especially the definition of variables after statements.
   The generated C parsers still aim at C90.
@@ -28,6 +20,9 @@ GNU Bison NEWS
   Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
   1.875): use %lex-param, %parse-param, or %param.
 
+  Missing semicolons at the end of actions are no longer added (as announced
+  in the release 2.5).
+
 ** Bug fixes
 
 *** The epilogue is no longer affected by internal #defines (glr.c)
@@ -221,6 +216,11 @@ GNU Bison NEWS
     bar.y: error: shift/reduce conflicts: 1 found, 0 expected
     bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
 
+** Incompatibilities with POSIX Yacc
+
+  The 'yacc' category is no longer part of '-Wall', enable it explicitly
+  with '-Wyacc'.
+
 ** Additional yylex/yyparse arguments
 
   The new directive %param declares additional arguments to both yylex and
@@ -252,6 +252,77 @@ GNU Bison NEWS
   use these prefixed token names, although the grammar itself still
   uses the short names (as in the sample rule given above).
 
+** Variable api.value.type
+
+  This new %define variable supersedes the #define macro YYSTYPE.  The use
+  of YYSTYPE is discouraged.  In particular, #defining YYSTYPE *and* either
+  using %union or %defining api.value.type results in undefined behavior.
+
+  Either define api.value.type, or use "%union":
+
+    %union
+    {
+      int ival;
+      char *sval;
+    }
+    %token <ival> INT "integer"
+    %token <sval> STRING "string"
+    %printer { fprintf (yyo, "%d", $$); } <ival>
+    %destructor { free ($$); } <sval>
+
+    /* In yylex().  */
+    yylval.ival = 42; return INT;
+    yylval.sval = "42"; return STRING;
+
+  The %define variable api.value.type supports several special values.  The
+  value "union" means that the user provides genuine types, not union member
+  names such as "ival" and "sval" above.
+
+    %define api.value.type "union"
+    %token <int> INT "integer"
+    %token <char *> STRING "string"
+    %printer { fprintf (yyo, "%d", $$); } <int>
+    %destructor { free ($$); } <char *>
+
+    /* In yylex().  */
+    yylval.INT = 42; return INT;
+    yylval.STRING = "42"; return STRING;
+
+  The value "variant" is somewhat equivalent, but for C++ special provision
+  is made to allow classes to be used (more about this below).
+
+    %define api.value.type "variant"
+    %token <int> INT "integer"
+    %token <std::string> STRING "string"
+
+  Any other name is a user type to use.  This is where YYSTYPE used to be
+  used.
+
+    %code requires
+    {
+      struct my_value
+      {
+        enum
+        {
+          is_int, is_string
+        } kind;
+        union
+        {
+          int ival;
+          char *sval;
+        } u;
+      };
+    }
+    %define api.value.type "struct my_value"
+    %token <u.ival> INT "integer"
+    %token <u.sval> STRING "string"
+    %printer { fprintf (yyo, "%d", $$); } <u.ival>
+    %destructor { free ($$); } <u.sval>
+
+    /* In yylex().  */
+    yylval.u.ival = 42; return INT;
+    yylval.u.sval = "42"; return STRING;
+
 ** Variable parse.error
 
   This variable controls the verbosity of error messages.  The use of the
@@ -284,11 +355,27 @@ GNU Bison NEWS
   It used to be an error only if used in non GLR mode, _and_ if there are
   reduce/reduce conflicts.
 
-** Token numbering has changed to preserve the user-defined order
+** Tokens are numbered in their order of appearance
+
+  Contributed by Valentin Tolmer.
+
+  With '%token A B', A had a number less than the one of B.  However,
+  precedence declarations used to generate a reversed order.  This is now
+  fixed, and introducing tokens with any of %token, %left, %right,
+  %precedence, or %nonassoc yields the same result.
+
+  When mixing declarations of tokens with a litteral character (e.g., 'a')
+  or with an identifier (e.g., B) in a precedence declaration, Bison
+  numbered the litteral characters first.  For example
+
+    %right A B 'c' 'd'
+
+  would lead to the tokens declared in this order: 'c' 'd' A B.  Again, the
+  input order is now preserved.
 
-  When declaring %token A B, the numbering for A is inferior to B. Up to now,
-  when declaring associativity at the same time, with %left (or %right,
-  %precedence, %nonassoc), B was inferior to A.
+  These changes were made so that one can remove useless precedence and
+  associativity declarations (i.e., map %nonassoc, %left or %right to
+  %precedence, or to %token) and get exactly the same output.
 
 ** Useless precedence and associativity
 
@@ -2520,7 +2607,7 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
  LocalWords:  Wprecedence Rassoul Wempty Paolo Bonzini parser's Michiel loc
  LocalWords:  redeclaration sval fcaret reentrant XSLT xsl Wmaybe yyvsp Tedi
  LocalWords:  pragmas noreturn untyped Rozenman unexpanded Wojciech Polak
- LocalWords:  Alexandre MERCHANTABILITY
+ LocalWords:  Alexandre MERCHANTABILITY yytype
 
 Local Variables:
 mode: outline