* Noteworthy changes in release ?.? (????-??-??) [?]
-** Incompatible changes
+** WARNING: Future backward-incompatibilities!
+
+ Like other GNU packages, Bison will start using some of the C99 features
+ for its own code, especially the definition of variables after statements.
+ The generated C parsers still aim at C90.
+
+** Backward incompatible changes
*** Obsolete features
Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
1.875): use %lex-param, %parse-param, or %param.
-** Warnings
+ Missing semicolons at the end of actions are no longer added (as announced
+ in the release 2.5).
+
+** Bug fixes
+
+*** The epilogue is no longer affected by internal #defines (glr.c)
+
+ The glr.c skeleton uses defines such as #define yylval (yystackp->yyval) in
+ generated code. These weren't properly undefined before the inclusion of
+ the user epilogue, so functions such as the following were butchered by the
+ preprocessor expansion:
+
+ int yylex (YYSTYPE *yylval);
+
+ This is fixed: yylval, yynerrs, yychar, and yylloc are now valid
+ identifiers for user-provided variables.
+
+*** stdio.h is no longer needed when locations are enabled (yacc.c)
+
+ Changes in Bison 2.7 introduced a dependency on FILE and fprintf when
+ locations are enabled. This is fixed.
+
+** Diagnostics reported by Bison
+
+ Most of these features were contributed by Théophile Ranquet and Victor
+ Santet.
+
+*** Carets
+
+ Version 2.7 introduced caret errors, for a prettier output. These are now
+ activated by default. The old format can still be used by invoking Bison
+ with -fno-caret (or -fnone).
+
+ Some error messages that reproduced excerpts of the grammar are now using
+ the caret information only. For instance on:
+
+ %%
+ exp: 'a' | 'a';
+
+ Bison 2.7 reports:
+
+ in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
+ in.y:2.12-14: warning: rule useless in parser due to conflicts: exp: 'a' [-Wother]
+
+ Now bison reports:
+
+ in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
+ in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
+ exp: 'a' | 'a';
+ ^^^
+
+ and "bison -fno-caret" reports:
+
+ in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
+ in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
*** Enhancements of the -Werror option
bar.y: error: shift/reduce conflicts: 1 found, 0 expected
bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
+** Incompatibilities with POSIX Yacc
+
+ The 'yacc' category is no longer part of '-Wall', enable it explicitly
+ with '-Wyacc'.
+
** Additional yylex/yyparse arguments
The new directive %param declares additional arguments to both yylex and
%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).
-
-** 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
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
It used to be an error only if used in non GLR mode, _and_ if there are
reduce/reduce conflicts.
+** Tokens are numbered in their order of appearance
+
+ Contributed by Valentin Tolmer.
+
+ With '%token A B', A had a number less than the one of B. However,
+ precedence declarations used to generate a reversed order. This is now
+ fixed, and introducing tokens with any of %token, %left, %right,
+ %precedence, or %nonassoc yields the same result.
+
+ 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
+
+ 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).
+
+*** %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);
+ ...
+ }
+
* Noteworthy changes in release 2.7 (2012-12-12) [stable]
** Bug fixes
** Diagnostics are improved
+ Contributed by Théophile Ranquet.
+
*** Changes in the format of error messages
This used to be the format of many error reports:
exp: exp '+' exp { $exp = $1 + $3; };
^^^
- The default behaviour for now is still not to display these unless
- explictly asked with -fcaret (or -fall). However, in a later release, it
+ The default behavior for now is still not to display these unless
+ explicitly asked with -fcaret (or -fall). However, in a later release, it
will be made the default behavior (but may still be deactivated with
-fno-caret).
** Graph improvements in DOT and XSLT
+ Contributed by Théophile Ranquet.
+
The graphical presentation of the states is more readable: their shape is
now rectangular, the state number is clearly displayed, and the items are
numbered and left-justified.
Other issues in the test suite have been addressed.
- Nul characters are correctly displayed in error messages.
+ Null characters are correctly displayed in error messages.
When possible, yylloc is correctly initialized before calling yylex. It
is no longer necessary to initialize it in the %initial-action.
These features are experimental. More user feedback will help to
stabilize them.
-** LAC (Lookahead Correction) for syntax error handling:
+** LAC (Lookahead Correction) for syntax error handling
+
+ Contributed by Joel E. Denny.
Canonical LR, IELR, and LALR can suffer from a couple of problems
upon encountering a syntax error. First, the parser might perform
-----
-Copyright (C) 1995-2012 Free Software Foundation, Inc.
+Copyright (C) 1995-2013 Free Software Foundation, Inc.
This file is part of Bison, the GNU Parser Generator.
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 Wother nterm arg init
- LocalWords: TOK calc yyo fval Wconflicts
+ LocalWords: TOK calc yyo fval Wconflicts parsers yystackp yyval yynerrs
+ LocalWords: Théophile Ranquet Santet fno fnone stype associativity Tolmer
+ LocalWords: Wprecedence Rassoul Wempty Paolo Bonzini parser's Michiel loc
+ LocalWords: redeclaration sval fcaret reentrant XSLT xsl Wmaybe yyvsp Tedi
+ LocalWords: pragmas noreturn untyped Rozenman unexpanded Wojciech Polak
+ LocalWords: Alexandre MERCHANTABILITY
Local Variables:
mode: outline
projects / bison.git / blobdiff