+ $ 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
+
+ Contributed by Paolo Bonzini.
+
+ 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).
+
+** Renamed %define variables
+
+ The following variables have been renamed for consistency. Backward
+ compatibility is ensured, but upgrading is recommended.
+
+ lr.default-reductions -> lr.default-reduction
+ lr.keep-unreachable-states -> lr.keep-unreachable-state
+ namespace -> api.namespace
+ stype -> api.value.type
+
+** Variable api.token.prefix
+
+ The variable api.token.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.token.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 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
+
+ Contributed by Paul Hilfinger.
+
+ 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.
+
+** Token numbering has changed to preserve the user-defined order
+
+ When declaring %token A B, the numbering for A is inferior to B. Up to now,
+ when declaring associativity at the same time, with %left (or %right,
+ %precedence, %nonassoc), B was inferior to A.
+
+** Useless precedence and associativity
+
+ When developping and maintaining a grammar, useless associativity and
+ precedence directives are common. They can be a nuisance: new ambiguities
+ arising are sometimes masked because their conflicts are resolved due to
+ the extra precedence or associativity information. Furthermore, it can
+ hinder the comprehension of a new grammar: one will wonder about the role
+ of a precedence, where in fact it is useless. The following changes aim
+ at detecting and reporting these extra directives.
+
+*** Precedence warning category
+
+ A new category of warning, -Wprecedence, was introduced. It flags the
+ useless precedence and associativity directives.
+
+*** Useless associativity
+
+ Bison now warns about symbols with a declared associativity that is never
+ used to resolve conflicts. In that case, using %precedence is sufficient;
+ the parsing tables will remain unchanged. Solving these warnings may raise
+ useless precedence warnings, as the symbols no longer have associativity.
+ For example:
+
+ %left '+'
+ %left '*'
+ %%
+ exp:
+ "num"
+ | exp '+' "num"
+ | exp '*' exp
+ ;
+
+ will produce a
+
+ warning: useless associativity for '+', use %precedence [-Wprecedence]
+ %left '+'
+ ^^^
+
+*** Useless precedence
+
+ Bison now warns about symbols with a declared precedence and no declared
+ associativity (i.e., declared with %precedence), and whose precedence is
+ never used. In that case, the symbol can be safely declared with %token
+ instead, without modifying the parsing tables. For example:
+
+ %precedence '='
+ %%
+ exp: "var" '=' "num";
+
+ will produce a
+
+ warning: useless precedence for '=' [-Wprecedence]
+ %precedence '='
+ ^^^
+
+*** Useless precedence and associativity
+
+ In case of both useless precedence and associativity, the issue is flagged
+ as follows:
+
+ %nonassoc '='
+ %%
+ exp: "var" '=' "num";
+
+ The warning is:
+
+ warning: useless precedence and associativity for '=' [-Wprecedence]
+ %nonassoc '='
+ ^^^
+
+* Noteworthy changes in release 2.7 (2012-12-12) [stable]
+
+** Bug fixes
+
+ Warnings about uninitialized yylloc in yyparse have been fixed.
+
+ Restored C90 compliance (yet no report was ever made).
+
+** Diagnostics are improved
+
+ Contributed by Théophile Ranquet.
+
+*** Changes in the format of error messages
projects / bison.git / blobdiff