** 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.
-*** Warning categories are now displayed
-
- For instance:
-
- foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
-
*** Useless semantic types
Bison now warns about useless (uninhabited) semantic types. Since
foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
$ bison -Werror foo.y
- bison: warnings being treated as errors
- foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
- foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
+ 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:
New one:
$ bison bar.y
- bar.y: shift/reduce conflicts: 1 found, 0 expected
- bar.y: reduce/reduce conflicts: 2 found, 0 expected
+ bar.y: error: shift/reduce conflicts: 1 found, 0 expected
+ bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
** Additional yylex/yyparse arguments
Incorrect definitions of YY_, issued by yacc.c when no parser header is
generated, are removed.
+** Changes in the format of error messages
+
+ This used to be the format of many error reports:
+
+ foo.y:5.10-24: result type clash on merge function 'merge': <t3> != <t2>
+ foo.y:4.13-27: previous declaration
+
+ It is now:
+
+ foo.y:5.10-25: result type clash on merge function 'merge': <t3> != <t2>
+ foo.y:4.13-27: previous declaration
+
+** Header guards (yacc.c, glr.c, glr.cc)
+
+ In order to avoid collisions, the header guards are now
+ YY_<PREFIX>_<FILE>_INCLUDED, instead of merely <PREFIX>_<FILE>.
+ For instance the header generated from
+
+ %define api.prefix "calc"
+ %defines "lib/parse.h"
+
+ will use YY_CALC_LIB_PARSE_H_INCLUDED as guard.
+
* Noteworthy changes in release 2.6.2 (2012-08-03) [stable]
** Bug fixes
projects / bison.git / blobdiff