X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/3cd7c0bfce1635ea344947aaf8fda4000b817a80..22539284f3220db77eae57f1c06846753c20de43:/NEWS

diff --git a/NEWS b/NEWS
index 14f51b3e..79fdb8ef 100644
--- a/NEWS
+++ b/NEWS
@@ -1,7 +1,74 @@
-Bison News
-----------
+GNU Bison NEWS
 
-* Changes in version 2.5.1_rc2 (2012-05-23):
+* Noteworthy changes in release ?.? (????-??-??) [?]
+
+** Additional yylex/yyparse arguments
+
+  The new directive %param declare additional argument to both yylex
+  and yyparse.  The %lex-param, %parse-param, and %param directives
+  support one or more arguments.  Instead of
+
+      %lex-param   {arg1_type *arg1}
+      %lex-param   {arg2_type *arg2}
+      %parse-param {arg1_type *arg1}
+      %parse-param {arg2_type *arg2}
+
+  one may now declare
+
+      %param {arg1_type *arg1} {arg2_type *arg2}
+
+** Java skeleton improvements
+
+  The constants for token names were moved to the Lexer interface.
+  Also, it is possible to add code to the parser's constructors using
+  "%code init" and "%define init_throws".
+
+** C++ skeleton improvements
+
+  The C++ parser features a syntax_error exception, which can be
+  thrown from the scanner or from user rules to raise syntax errors.
+  This facilitates reporting errors caught in sub-functions (e.g.,
+  rejecting too large integral literals from a conversion function
+  used by the scanner, or rejecting invalid combinations from a
+  factory invoked by the user actions).
+
+** Variable api.tokens.prefix
+
+  The variable api.tokens.prefix changes the way tokens are identified in
+  the generated files.  This is especially useful to avoid collisions
+  with identifiers in the target language.  For instance
+
+      %token FILE for ERROR
+      %define api.tokens.prefix "TOK_"
+      %%
+      start: FILE for ERROR;
+
+  will generate the definition of the symbols TOK_FILE, TOK_for, and
+  TOK_ERROR in the generated sources.  In particular, the scanner must
+  use these prefixed token names, although the grammar itself still
+  uses the short names (as in the sample rule given above).
+
+** Variable api.namespace
+
+  The "namespace" variable is renamed "api.namespace".  Backward
+  compatibility is ensured, but upgrading is recommended.
+
+** Variable parse.error
+
+  The variable error controls the verbosity of error messages.  The
+  use of the %error-verbose directive is deprecated in favor of
+  %define parse.error "verbose".
+
+** Semantic predicates
+
+  The new, experimental, semantic-predicate feature allows actions of
+  the form %?{ BOOLEAN-EXPRESSION }, which cause syntax errors (as for
+  YYERROR) if the expression evaluates to 0, and are evaluated immediately
+  in GLR parsers, rather than being deferred.  The result is that they
+  allow the programmer to prune possible parses based on the values of
+  runtime expressions.
+
+* Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
 
 ** Future changes:
 
@@ -93,7 +160,7 @@ Bison News
   This includes warnings with some compilers, unexpected behavior of tools
   such as diff, warning messages from the test suite itself, etc.
 
-*** The install-pdf target work properly:
+*** The install-pdf target works properly:
 
   Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
   halts in the middle of its course.
@@ -928,26 +995,26 @@ Bison News
   if the symbols have destructors.  For instance:
 
      exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
-	| exp "+" exp
-	;
+        | exp "+" exp
+        ;
 
   will trigger a warning about $$ and $5 in the first rule, and $3 in
   the second ($1 is copied to $$ by the default rule).  This example
   most likely contains three errors, and could be rewritten as:
 
      exp: exp "?" exp ":" exp
-	    { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
-	| exp "+" exp
-	    { $$ = $1 ? $1 : $3; if ($1) free ($3); }
-	;
+            { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
+        | exp "+" exp
+            { $$ = $1 ? $1 : $3; if ($1) free ($3); }
+        ;
 
   However, if the original actions were really intended, memory leaks
   and all, the warnings can be suppressed by letting Bison believe the
   values are used, e.g.:
 
      exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
-	| exp "+" exp         { $$ = $1; (void) $3; }
-	;
+        | exp "+" exp         { $$ = $1; (void) $3; }
+        ;
 
   If there are mid-rule actions, the warning is issued if no action
   uses it.  The following triggers no warning: $1 and $3 are used.
@@ -1191,16 +1258,16 @@ Bison News
   In agreement with POSIX and with other Yaccs, leaving a default
   action is valid when $$ is untyped, and $1 typed:
 
-	untyped: ... typed;
+        untyped: ... typed;
 
   but the converse remains an error:
 
-	typed: ... untyped;
+        typed: ... untyped;
 
 ** Values of mid-rule actions
   The following code:
 
-	foo: { ... } { $$ = $1; } ...
+        foo: { ... } { $$ = $1; } ...
 
   was incorrectly rejected: $1 is defined in the second mid-rule
   action, and is equal to the $$ of the first mid-rule action.