warnings: raise warning for useless printers or destructors

[bison.git] / NEWS

diff --git a/NEWS b/NEWS
index 03ab1578d42dd98f9508c7c5c0fea6da20e8c3e5..286547696d24325ccfac0396d20e976f642ac563 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,23 @@ GNU Bison NEWS
 
 * Noteworthy changes in release ?.? (????-??-??) [?]
 
+** Warnings about useless semantic types
+
+  Bison now warns about useless (uninhabited) semantic types.  Since
+  semantic types are not declared to Bison (they are defined in the opaque
+  %union structure), it is %printer/%destructor directives about useless
+  types that trigger the warning:
+
+    %token <type1> term
+    %type  <type2> nterm
+    %printer    {} <type1> <type3>
+    %destructor {} <type2> <type4>
+    %%
+    nterm: term { $$ = $1; };
+
+    3.28-34: warning: type <type3> is used, but is not associated to any symbol
+    4.28-34: warning: type <type4> is used, but is not associated to any symbol
+
 ** Warnings about undeclared symbols
 
   Bison used to raise an error for %printer and %destructor directives for
@@ -14,6 +31,20 @@ GNU Bison NEWS
 
   This is now only a warning.
 
+** Warnings about useless destructors or printers
+
+  Bison now warns about useless destructors or printers.  In the following
+  example, the printer for <type1>, and the destructor for <type2> are
+  useless: all symbols of <type1> (token1) already have a printer, and all
+  symbols of type <type2> (token2) already have a destructor.
+
+    %token <type1> token1
+           <type2> token2
+           <type3> token3
+           <type4> token4
+    %printer    {} token1 <type1> <type3>
+    %destructor {} token2 <type2> <type4>
+
 ** Additional yylex/yyparse arguments
 
   The new directive %param declares additional arguments to both yylex and
@@ -85,8 +116,10 @@ GNU Bison NEWS
 ** Future changes:
 
   The next major release will drop support for generating parsers in K&R C,
-  and remove the definition of yystype (removal announced since Bison
-  1.875).
+  and remove the definitions of yystype and yyltype (removal announced since
+  Bison 1.875).  YYPARSE_PARAM and YYLEX_PARAM, which were deprecated in
+  favor of %parse-param and %lex-param (introduced in Bison 1.875 too), will
+  no longer be supported.
 
 ** The generated header is included (yacc.c)
 
@@ -1282,6 +1315,33 @@ GNU Bison NEWS
   - "parsing stack overflow..." -> "parser stack overflow"
     GLR parsers now report "parser stack overflow" as per the Bison manual.
 
+** %parse-param and %lex-param
+  The macros YYPARSE_PARAM and YYLEX_PARAM provide a means to pass
+  additional context to yyparse and yylex.  They suffer from several
+  shortcomings:
+
+  - a single argument only can be added,
+  - their types are weak (void *),
+  - this context is not passed to anciliary functions such as yyerror,
+  - only yacc.c parsers support them.
+
+  The new %parse-param/%lex-param directives provide a more precise control.
+  For instance:
+
+    %parse-param {int *nastiness}
+    %lex-param   {int *nastiness}
+    %parse-param {int *randomness}
+
+  results in the following signatures:
+
+    int yylex   (int *nastiness);
+    int yyparse (int *nastiness, int *randomness);
+
+  or, if both %pure-parser and %locations are used:
+
+    int yylex   (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
+    int yyparse (int *nastiness, int *randomness);
+
 ** Bison now warns if it detects conflicting outputs to the same file,
   e.g., it generates a warning for "bison -d -o foo.h foo.y" since
   that command outputs both code and header to foo.h.