X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/f0f95a50ee91374ac42b13f201aa42c2038fcada..cc2235ace2d91338663caeec288743092a6b3aeb:/NEWS diff --git a/NEWS b/NEWS index c94af176..be3669a9 100644 --- a/NEWS +++ b/NEWS @@ -2,9 +2,10 @@ GNU Bison NEWS * Noteworthy changes in release ?.? (????-??-??) [?] -** Future changes +** WARNING: Future backward-incompatibilities! - Bison will stop adding a semicolon at the end of the actions: + Bison will stop adding a semicolon at the end of the actions (as announced + in the release 2.5): foo.y:2.22: warning: a ';' might be needed at the end of action code exp: "num" { $$ = $1 } @@ -15,7 +16,7 @@ GNU Bison NEWS for its own code, especially the definition of variables after statements. The generated C parsers still aim at C90. -** Incompatible changes +** Backward incompatible changes *** Obsolete features @@ -289,6 +290,82 @@ GNU Bison NEWS 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 @@ -299,6 +376,8 @@ GNU Bison NEWS ** 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: @@ -384,6 +463,8 @@ GNU Bison NEWS ** 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. @@ -825,7 +906,9 @@ GNU Bison NEWS 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