+ When mixing declarations of tokens with a litteral character (e.g., 'a')
+ or with an identifier (e.g., B) in a precedence declaration, Bison
+ numbered the litteral characters first. For example
+
+ %right A B 'c' 'd'
+
+ would lead to the tokens declared in this order: 'c' 'd' A B. Again, the
+ input order is now preserved.
+
+ These changes were made so that one can remove useless precedence and
+ associativity declarations (i.e., map %nonassoc, %left or %right to
+ %precedence, or to %token) and get exactly the same output.
+
+** 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 {};
+ ^^^^^^
+
+** 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".
+ Contributed by Paolo Bonzini.
+
+ The Java skeleton now supports push parsing.
+ Contributed by Dennis Heimbigner.
+
+** 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).
+
+*** %define api.value.type variant
+
+ This is based on a submission from Michiel De Wilde. With help
+ from Théophile Ranquet.
+
+ In this mode, complex C++ objects can be used as semantic values. For
+ instance:
+
+ %token <::std::string> TEXT;
+ %token <int> NUMBER;
+ %token SEMICOLON ";"
+ %type <::std::string> item;
+ %type <::std::list<std::string>> list;
+ %%
+ result:
+ list { std::cout << $1 << std::endl; }
+ ;
+
+ list:
+ %empty { /* Generates an empty string list. */ }
+ | list item ";" { std::swap ($$, $1); $$.push_back ($2); }
+ ;
+
+ item:
+ TEXT { std::swap ($$, $1); }
+ | NUMBER { $$ = string_cast ($1); }
+ ;
+
+*** %define api.token.constructor
+
+ When variants are enabled, Bison can generate functions to build the
+ tokens. This guarantees that the token type (e.g., NUMBER) is consistent
+ with the semantic value (e.g., int):
+
+ parser::symbol_type yylex ()
+ {
+ parser::location_type loc = ...;
+ ...
+ return parser::make_TEXT ("Hello, world!", loc);
+ ...
+ return parser::make_NUMBER (42, loc);
+ ...
+ return parser::make_SEMICOLON (loc);
+ ...
+ }
+
+*** C++ locations
+
+ There are operator- and operator-= for 'location'. Negative line/column
+ increments can no longer underflow the resulting value.
+
+* Noteworthy changes in release 2.7.1 (2013-04-15) [stable]
+
+** Bug fixes
projects / bison.git / blobdiff