* 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
+ undefined symbols.
+
+ %printer {} symbol1
+ %destructor {} symbol2
+ %%
+ exp: "a";
+
+ 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
+ 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 ?.? (????-??-??) [?]
+
** Future changes
The next major release of Bison will drop support for the following
generated for C supprt ISO C90, and are tested with ISO C99 and ISO C11
compilers.
-*** Deprecated features
+*** Features deprecated since Bison 1.875
- The definitions of yystype and yyltype will be removed, as announced since
- Bison 1.875. Use YYSTYPE and YYLTYPE only.
+ The definitions of yystype and yyltype will be removed; use YYSTYPE and
+ YYLTYPE.
- YYPARSE_PARAM and YYLEX_PARAM, which were deprecated in favor of
- %parse-param and %lex-param (introduced in Bison 1.875), will no longer be
- supported.
+ YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and
+ %lex-param, will no longer be supported.
+
+ Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use
+ %error-verbose.
*** The generated header will be included (yacc.c)
because existing versions of ylwrap (e.g., Automake 1.12.1) do not support
it.
-** Headers (yacc.c, glr.c, glr.cc)
+** Headers
-*** Guards
+*** Guards (yacc.c, glr.c, glr.cc)
The generated headers are now guarded, as is already the case for C++
parsers (lalr1.cc). For intance, with --defines=foo.h:
...
#endif /* !YY_FOO_H */
-*** New declarations
+*** New declarations (yacc.c, glr.c)
The generated header now declares yydebug and yyparse. Both honor
--name-prefix=bar_, and yield
in order to facilitate the inclusion of several parser headers inside a
single compilation unit.
+*** Exported symbols in C++
+
+ The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the
+ header, are removed, as they prevent the possibility of including several
+ generated headers from a single compilation unit.
+
+*** YYLSP_NEEDED
+
+ For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no
+ longer defined.
+
* Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
** Future changes: