* Noteworthy changes in release ?.? (????-??-??) [?]
+** Incompatible changes
+
+*** Obsolete features
+
+ Support for YYFAIL is removed (deprecated in Bison 2.4.2).
+ Support for yystype and yyltype (instead of YYSTYPE and YYLTYPE)
+ is removed (deprecated in Bison 1.875).
+ Support for YYPARSE_PARAM is removed (deprecated in Bison 1.875).
+
+** Warnings
+
+*** Enhancements of the -Werror option
+
+ The -Werror=CATEGORY option is now recognized, and will treat specified
+ warnings as errors. The warnings need not have been explictly activated
+ using the -W option, this is similar to what gcc 4.7 does.
+
+ For example, given the following command line, Bison will treat both
+ warnings related to POSIX Yacc incompatiblities and S/R conflicts as
+ errors (and only those):
+
+ $ bison -Werror=yacc,error=conflicts-sr input.y
+
+ If no categories are specified, -Werror will make all active warnings into
+ errors. For example, the following line does the same the previous example:
+
+ $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y
+
+ (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)
+
+ Note that the categories in this -Werror option may not be prefixed with
+ "no-". However, -Wno-error[=CATEGORY] is valid.
+
+ Note that -y enables -Werror=yacc. Therefore it is now possible to require
+ Yacc-like behavior (e.g., always generate y.tab.c), but to report
+ incompatibilities as warnings: "-y -Wno-error=yacc".
+
+*** The display of warnings is now richer
+
+ The option that controls a given warning is now displayed:
+
+ foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
+
+ In the case of warnings treated as errors, the prefix is changed from
+ "warning: " to "error: ", and the suffix is displayed, in a manner similar
+ to gcc, as [-Werror=CATEGORY].
+
+ For instance, where the previous version of Bison would report (and exit
+ with failure):
+
+ bison: warnings being treated as errors
+ input.y:1.1: warning: stray ',' treated as white space
+
+ it now reports:
+
+ input.y:1.1: error: stray ',' treated as white space [-Werror=other]
+
+*** Deprecated constructs
+
+ The new 'deprecated' warning category flags obsolete constructs whose
+ support will be discontinued. It is enabled by default. These warnings
+ used to be reported as 'other' warnings.
+
+*** 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
+
+*** Undefined but unused symbols
+
+ Bison used to raise an error for undefined symbols that are not used in
+ the grammar. This is now only a warning.
+
+ %printer {} symbol1
+ %destructor {} symbol2
+ %type <type> symbol3
+ %%
+ exp: "a";
+
+*** 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>
+
+*** Conflicts
+
+ The warnings and error messages about shift/reduce and reduce/reduce
+ conflicts have been normalized. For instance on the following foo.y file:
+
+ %glr-parser
+ %%
+ exp: exp '+' exp | '0' | '0';
+
+ compare the previous version of bison:
+
+ $ bison foo.y
+ foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
+ $ bison -Werror foo.y
+ bison: warnings being treated as errors
+ foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
+
+ with the new behavior:
+
+ $ bison foo.y
+ foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
+ foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
+ $ bison -Werror foo.y
+ foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
+ foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]
+
+ When %expect or %expect-rr is used, such as with bar.y:
+
+ %expect 0
+ %glr-parser
+ %%
+ exp: exp '+' exp | '0' | '0';
+
+ Former behavior:
+
+ $ bison bar.y
+ bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
+ bar.y: expected 0 shift/reduce conflicts
+ bar.y: expected 0 reduce/reduce conflicts
+
+ New one:
+
+ $ bison bar.y
+ bar.y: error: shift/reduce conflicts: 1 found, 0 expected
+ bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
+
+** 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++ skeletons improvements
+
+*** The parser header is no longer mandatory (lalr1.cc, glr.cc)
+
+ Using %defines is now optional. Without it, the needed support classes
+ are defined in the generated parser, instead of additional files (such as
+ location.hh, position.hh and stack.hh).
+
+*** Locations are no longer mandatory (lalr1.cc, glr.cc)
+
+ Both lalr1.cc and glr.cc no longer require %location.
+
+*** syntax_error exception (lalr1.cc)
+
+ 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
+
+ This variable 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 run-time
+ expressions.
+
+** The directive %expect-rr is now an error in non GLR mode
+
+ It used to be an error only if used in non GLR mode, _and_ if there are
+ reduce/reduce conflicts.
+
+* Noteworthy changes in release ?.? (????-??-??) [?]
+
** Bug fixes
Bugs and portability issues in the test suite have been fixed.
then responsible to define her type.
This can be used in programs with several parsers to factor their location
- and position files: let one of them generate them, and let the others
- simply resue these types and files.
+ and position files: let one of them generate them, and the others just use
+ them.
This feature was actually introduced, but not documented, in Bison 2.5,
under the name "location_type" (which is maintained for backward
* Noteworthy changes in release 2.6.1 (2012-07-30) [stable]
- Bison no longer executes user-specified M4 code when processing a grammar.
+ Bison no longer executes user-specified M4 code when processing a grammar.
** Future Changes
* Noteworthy changes in release 2.6 (2012-07-19) [stable]
-** Future Changes
+** Future changes:
The next major release of Bison will drop support for the following
deprecated features. Please report disagreements to bug-bison@gnu.org.
LocalWords: namespaces strerror const autoconfiguration Dconst Autoconf's FDL
LocalWords: Automake TMPDIR LESSEQ ylwrap endif yydebug YYTOKEN YYLSP ival hh
LocalWords: extern YYTOKENTYPE TOKENTYPE yytokentype tokentype STYPE lval pdf
- LocalWords: lang yyoutput dvi html ps POSIX lvalp llocp calc yyo fval
+ LocalWords: lang yyoutput dvi html ps POSIX lvalp llocp Wother nterm arg init
+ LocalWords: TOK calc yyo fval
Local Variables:
mode: outline
projects / bison.git / blobdiff