]> git.saurik.com Git - bison.git/blobdiff - NEWS
Clean up yesterday's patch.
[bison.git] / NEWS
diff --git a/NEWS b/NEWS
index 702f45b715821be9ec5a4c23881d4bc3d0f641ea..dd36e633ad222f2632b280e160801978147a8d0a 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -1,11 +1,99 @@
 Bison News
 ----------
 
 Bison News
 ----------
 
-Changes in version 2.1b:
-
-* No user-visible changes.
-
-Changes in version 2.1a, 2006-02-13:
+Changes in version 2.3+:
+
+* 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
+  helps to sanitize the global namespace during preprocessing, but POSIX Yacc
+  requires them.  Bison still generates an enum for token names in all cases.
+
+* Handling of traditional Yacc prologue blocks is now more consistent but
+  potentially incompatible with previous releases of Bison.
+
+  As before, you declare prologue blocks in your grammar file with the
+  `%{ ... %}' 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.  
+
+  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
+  latter case, Bison inserted it only into the code file.  For parsers in C++,
+  the point of insertion was before any token definitions (which associate
+  token numbers with names).  For parsers in C, the point of insertion was
+  after the token definitions.
+
+  Now, Bison never inserts the pre-prologue into the header file.  In the code
+  file, it always inserts it before the token definitions.
+
+* Bison now provides a more flexible alternative to the traditional Yacc
+  prologue blocks: %before-header, %start-header, %end-header, and
+  %after-header.
+
+  For example, the following declaration order in the grammar file reflects the
+  order in which Bison will output these code blocks.  However, you are free to
+  declare these code blocks in your grammar file in whatever order is most
+  convenient for you:
+
+    %before-header {
+      /* Bison treats this block like a pre-prologue block: it inserts it into
+       * the code file before the contents of the header file.  It does *not*
+       * insert it into the header file.  This is a good place to put
+       * #include's that you want at the top of your code file.  A common
+       * example is `#include "system.h"'.  */
+    }
+    %start-header {
+      /* Bison inserts this block into both the header file and the code file.
+       * In both files, the point of insertion is before any Bison-generated
+       * token, semantic type, location type, and class definitions.  This is a
+       * good place to define %union dependencies, for example.  */
+    }
+    %union {
+      /* Unlike the traditional Yacc prologue blocks, the output order for the
+       * new %*-header blocks is not affected by their declaration position
+       * relative to any %union in the grammar file.  */
+    }
+    %end-header {
+      /* Bison inserts this block into both the header file and the code file.
+       * In both files, the point of insertion is after the Bison-generated
+       * definitions.  This is a good place to declare or define public
+       * functions or data structures that depend on the Bison-generated
+       * definitions.  */
+    }
+    %after-header {
+      /* Bison treats this block like a post-prologue block: it inserts it into
+       * the code file after the contents of the header file.  It does *not*
+       * insert it into the header file.  This is a good place to declare or
+       * define internal functions or data structures that depend on the
+       * Bison-generated definitions.  */
+    }
+
+  If you have multiple occurrences of any one of the above declarations, Bison
+  will concatenate the contents in declaration order.
+
+* The option `--report=look-ahead' has been changed to `--report=lookahead'.
+  The old spelling still works, but is not documented and may be removed
+  in a future release.
+
+Changes in version 2.3, 2006-06-05:
+
+* GLR grammars should now use `YYRECOVERING ()' instead of `YYRECOVERING',
+  for compatibility with LALR(1) grammars.
+
+* It is now documented that any definition of YYSTYPE or YYLTYPE should
+  be to a type name that does not contain parentheses or brackets.
+
+Changes in version 2.2, 2006-05-19:
+
+* The distribution terms for all Bison-generated parsers now permit
+  using the parsers in nonfree programs.  Previously, this permission
+  was granted only for Bison-generated LALR(1) parsers in C.
+
+* %name-prefix changes the namespace name in C++ outputs.
+
+* The C++ parsers export their token_type.
 
 * Bison now allows multiple %union declarations, and concatenates
   their contents together.
 
 * Bison now allows multiple %union declarations, and concatenates
   their contents together.
@@ -75,10 +163,10 @@ Changes in version 2.1a, 2006-02-13:
   for previous releases of Bison, and this one.
 
   If you wish to update, then make sure older version of Bison will
   for previous releases of Bison, and this one.
 
   If you wish to update, then make sure older version of Bison will
-  fail using `%require "2.1a"'.
+  fail using `%require "2.2"'.
 
 * DJGPP support added.
 
 * DJGPP support added.
-
+\f
 Changes in version 2.1, 2005-09-16:
 
 * The C++ lalr1.cc skeleton supports %lex-param.
 Changes in version 2.1, 2005-09-16:
 
 * The C++ lalr1.cc skeleton supports %lex-param.
@@ -104,7 +192,7 @@ Changes in version 2.1, 2005-09-16:
   a syntax error associated with '%token NUM "number"' they might
   print 'syntax error, unexpected number' instead of 'syntax error,
   unexpected "number"'.
   a syntax error associated with '%token NUM "number"' they might
   print 'syntax error, unexpected number' instead of 'syntax error,
   unexpected "number"'.
-
+\f
 Changes in version 2.0, 2004-12-25:
 
 * Possibly-incompatible changes
 Changes in version 2.0, 2004-12-25:
 
 * Possibly-incompatible changes
@@ -147,8 +235,7 @@ Changes in version 2.0, 2004-12-25:
     This is a GNU extension.
 
   - The option `--report=lookahead' was changed to `--report=look-ahead'.
     This is a GNU extension.
 
   - The option `--report=lookahead' was changed to `--report=look-ahead'.
-    The old spelling still works, but is not documented and will be
-    removed.
+    [However, this was changed back after 2.3.]
 
   - Experimental %destructor support has been added to lalr1.cc.
 
 
   - Experimental %destructor support has been added to lalr1.cc.
 
@@ -415,8 +502,8 @@ Changes in version 1.50, 2002-10-04:
   produces additional information:
   - itemset
     complete the core item sets with their closure
   produces additional information:
   - itemset
     complete the core item sets with their closure
-  - lookahead [changed to `look-ahead' in 1.875e and later]
-    explicitly associate look-ahead tokens to items
+  - lookahead [changed to `look-ahead' in 1.875e through 2.3, but changed back]
+    explicitly associate lookahead tokens to items
   - solved
     describe shift/reduce conflicts solving.
     Bison used to systematically output this information on top of
   - solved
     describe shift/reduce conflicts solving.
     Bison used to systematically output this information on top of