+** 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".
+
+** 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
+
+** 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
+
+ Contributed by Valentin Tolmer.
+
+ When developing 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:
+ "number"
+ | exp '+' "number"
+ | 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" '=' "number";
+
+ 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" '=' "number";
+
+ The warning is:
+
+ warning: useless precedence and associativity for '=' [-Wprecedence]
+ %nonassoc '='
+ ^^^
+
+** Empty rules
+
+ With help from Joel E. Denny and Gabriel Rassoul.
+
+ Empty rules (i.e., with an empty right-hand side) can now be explicitly
+ marked by the new %empty directive. Using %empty on a non-empty rule is
+ an error. The new -Wempty-rule warning reports empty rules without
+ %empty. On the following grammar:
+
+ %%
+ s: a b c;
+ a: ;
+ b: %empty;
+ c: 'a' %empty;
+
+ bison reports:
+
+ 3.4-5: warning: empty rule without %empty [-Wempty-rule]
+ a: {}
+ ^^
+ 5.8-13: error: %empty on non-empty rule
+ c: 'a' %empty {};
+ ^^^^^^
+
projects / bison.git / blobdiff