Bison News
----------
-Changes in version 1.75d:
+Changes in version 2.3a+ (????-??-??):
+
+* The -g and --graph options now output graphs in Graphviz DOT format,
+ not VCG format.
+
+* The Yacc prologue alternatives from Bison 2.3a have been rewritten as the
+ following directives:
+
+ 1. %code {CODE}
+
+ Other than semantic actions, this is probably the most common place you
+ should write verbatim code for the parser implementation. For C/C++, it
+ replaces the traditional Yacc prologue, `%{CODE%}', for most purposes.
+ For Java, it inserts your CODE into the parser class. Compare with:
+
+ - `%{CODE%}' appearing after the first `%union {CODE}' in a C/C++
+ based grammar file. While Bison will continue to support `%{CODE%}'
+ for backward compatibility, `%code {CODE}' is cleaner as its
+ functionality does not depend on its position in the grammar file
+ relative to any `%union {CODE}'. Specifically, `%code {CODE}'
+ always inserts your CODE into the parser code file after the usual
+ contents of the parser header file.
+ - `%after-header {CODE}', which only Bison 2.3a supported.
+
+ 2. %requires {CODE}
+
+ This is the right place to write dependency code for externally exposed
+ definitions required by Bison. For C/C++, such exposed definitions are
+ those usually appearing in the parser header file. Thus, this is the
+ right place to define types referenced in `%union {CODE}' directives,
+ and it is the right place to override Bison's default YYSTYPE and
+ YYLTYPE definitions. For Java, this is the right place to write import
+ directives. Compare with:
+
+ - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
+ based grammar file. Unlike `%{CODE%}', `%requires {CODE}' inserts
+ your CODE both into the parser code file and into the parser header
+ file since Bison's required definitions should depend on it in both
+ places.
+ - `%start-header {CODE}', which only Bison 2.3a supported.
+
+ 3. %provides {CODE}
+
+ This is the right place to write additional definitions you would like
+ Bison to expose externally. For C/C++, this directive inserts your CODE
+ both into the parser header file and into the parser code file after
+ Bison's required definitions. For Java, it inserts your CODE into the
+ parser java file after the parser class. Compare with:
+
+ - `%end-header {CODE}', which only Bison 2.3a supported.
+
+ 4. %code-top {CODE}
+
+ Occasionally for C/C++ it is desirable to insert code near the top of
+ the parser code file. For example:
+
+ %code-top {
+ #define _GNU_SOURCE
+ #include <stdio.h>
+ }
+
+ For Java, `%code-top {CODE}' is currently unused. Compare with:
+
+ - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
+ based grammar file. `%code-top {CODE}' is cleaner as its
+ functionality does not depend on its position in the grammar file
+ relative to any `%union {CODE}'.
+ - `%before-header {CODE}', which only Bison 2.3a supported.
+
+ If you have multiple occurrences of any one of the above four directives,
+ Bison will concatenate the contents in the order they appear in the grammar
+ file.
+
+ Also see the new section `Prologue Alternatives' in the Bison manual.
+
+Changes in version 2.3a, 2006-09-13:
+
+* Instead of %union, you can define and use your own union type
+ YYSTYPE if your grammar contains at least one <type> tag.
+ Your YYSTYPE need not be a macro; it can be a typedef.
+ This change is for compatibility with other Yacc implementations,
+ and is required by POSIX.
+
+* Locations columns and lines start at 1.
+ In accordance with the GNU Coding Standards and Emacs.
+
+* You may now declare per-type and default %destructor's and %printer's:
+
+ For example:
+
+ %union { char *string; }
+ %token <string> STRING1
+ %token <string> STRING2
+ %type <string> string1
+ %type <string> string2
+ %union { char character; }
+ %token <character> CHR
+ %type <character> chr
+ %destructor { free ($$); } %symbol-default
+ %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
+ %destructor { } <character>
+
+ guarantees that, when the parser discards any user-defined symbol that has a
+ semantic type tag other than `<character>', it passes its semantic value to
+ `free'. However, when the parser discards a `STRING1' or a `string1', it
+ also prints its line number to `stdout'. It performs only the second
+ `%destructor' in this case, so it invokes `free' only once.
+
+* Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with `-y',
+ `--yacc', or `%yacc'), Bison no longer generates #define statements for
+ associating token numbers with token names. Removing the #define statements
+ helps to sanitize the global namespace during preprocessing, but POSIX Yacc
+ requires them. Bison still generates an enum for token names in all cases.
+
+* Handling of traditional Yacc prologue blocks is now more consistent but
+ potentially incompatible with previous releases of Bison.
+
+ As before, you declare prologue blocks in your grammar file with the
+ `%{ ... %}' syntax. To generate the pre-prologue, Bison concatenates all
+ prologue blocks that you've declared before the first %union. To generate
+ the post-prologue, Bison concatenates all prologue blocks that you've
+ declared after the first %union.
+
+ Previous releases of Bison inserted the pre-prologue into both the header
+ file and the code file in all cases except for LALR(1) parsers in C. In the
+ latter case, Bison inserted it only into the code file. For parsers in C++,
+ the point of insertion was before any token definitions (which associate
+ token numbers with names). For parsers in C, the point of insertion was
+ after the token definitions.
+
+ Now, Bison never inserts the pre-prologue into the header file. In the code
+ file, it always inserts it before the token definitions.
+
+* Bison now provides a more flexible alternative to the traditional Yacc
+ prologue blocks: %before-header, %start-header, %end-header, and
+ %after-header.
+
+ For example, the following declaration order in the grammar file reflects the
+ order in which Bison will output these code blocks. However, you are free to
+ declare these code blocks in your grammar file in whatever order is most
+ convenient for you:
+
+ %before-header {
+ /* Bison treats this block like a pre-prologue block: it inserts it into
+ * the code file before the contents of the header file. It does *not*
+ * insert it into the header file. This is a good place to put
+ * #include's that you want at the top of your code file. A common
+ * example is `#include "system.h"'. */
+ }
+ %start-header {
+ /* Bison inserts this block into both the header file and the code file.
+ * In both files, the point of insertion is before any Bison-generated
+ * token, semantic type, location type, and class definitions. This is a
+ * good place to define %union dependencies, for example. */
+ }
+ %union {
+ /* Unlike the traditional Yacc prologue blocks, the output order for the
+ * new %*-header blocks is not affected by their declaration position
+ * relative to any %union in the grammar file. */
+ }
+ %end-header {
+ /* Bison inserts this block into both the header file and the code file.
+ * In both files, the point of insertion is after the Bison-generated
+ * definitions. This is a good place to declare or define public
+ * functions or data structures that depend on the Bison-generated
+ * definitions. */
+ }
+ %after-header {
+ /* Bison treats this block like a post-prologue block: it inserts it into
+ * the code file after the contents of the header file. It does *not*
+ * insert it into the header file. This is a good place to declare or
+ * define internal functions or data structures that depend on the
+ * Bison-generated definitions. */
+ }
+
+ If you have multiple occurrences of any one of the above declarations, Bison
+ will concatenate the contents in declaration order.
+
+* The option `--report=look-ahead' has been changed to `--report=lookahead'.
+ The old spelling still works, but is not documented and may be removed
+ in a future release.
+
+Changes in version 2.3, 2006-06-05:
+
+* GLR grammars should now use `YYRECOVERING ()' instead of `YYRECOVERING',
+ for compatibility with LALR(1) grammars.
+
+* It is now documented that any definition of YYSTYPE or YYLTYPE should
+ be to a type name that does not contain parentheses or brackets.
+
+Changes in version 2.2, 2006-05-19:
+
+* The distribution terms for all Bison-generated parsers now permit
+ using the parsers in nonfree programs. Previously, this permission
+ was granted only for Bison-generated LALR(1) parsers in C.
+
+* %name-prefix changes the namespace name in C++ outputs.
+
+* The C++ parsers export their token_type.
+
+* Bison now allows multiple %union declarations, and concatenates
+ their contents together.
+
+* New warning: unused values
+ Right-hand side symbols whose values are not used are reported,
+ if the symbols have destructors. For instance:
+
+ exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
+ | exp "+" exp
+ ;
+
+ will trigger a warning about $$ and $5 in the first rule, and $3 in
+ the second ($1 is copied to $$ by the default rule). This example
+ most likely contains three errors, and could be rewritten as:
+
+ exp: exp "?" exp ":" exp
+ { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
+ | exp "+" exp
+ { $$ = $1 ? $1 : $3; if ($1) free ($3); }
+ ;
+
+ However, if the original actions were really intended, memory leaks
+ and all, the warnings can be suppressed by letting Bison believe the
+ values are used, e.g.:
+
+ exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
+ | exp "+" exp { $$ = $1; (void) $3; }
+ ;
+
+ If there are mid-rule actions, the warning is issued if no action
+ uses it. The following triggers no warning: $1 and $3 are used.
+
+ exp: exp { push ($1); } '+' exp { push ($3); sum (); };
+
+ The warning is intended to help catching lost values and memory leaks.
+ If a value is ignored, its associated memory typically is not reclaimed.
+
+* %destructor vs. YYABORT, YYACCEPT, and YYERROR.
+ Destructors are now called when user code invokes YYABORT, YYACCEPT,
+ and YYERROR, for all objects on the stack, other than objects
+ corresponding to the right-hand side of the current rule.
+
+* %expect, %expect-rr
+ Incorrect numbers of expected conflicts are now actual errors,
+ instead of warnings.
+
+* GLR, YACC parsers.
+ The %parse-params are available in the destructors (and the
+ experimental printers) as per the documentation.
+
+* Bison now warns if it finds a stray `$' or `@' in an action.
+
+* %require "VERSION"
+ This specifies that the grammar file depends on features implemented
+ in Bison version VERSION or higher.
-* Semicolons are once again optional at the end of grammar rules.
- This reverts to the behavior of Bison 1.33 and earlier, and improves
- compatibility with Yacc.
+* lalr1.cc: The token and value types are now class members.
+ The tokens were defined as free form enums and cpp macros. YYSTYPE
+ was defined as a free form union. They are now class members:
+ tokens are enumerations of the `yy::parser::token' struct, and the
+ semantic values have the `yy::parser::semantic_type' type.
-* Type clashes now generate warnings, not errors.
+ If you do not want or can update to this scheme, the directive
+ `%define "global_tokens_and_yystype" "1"' triggers the global
+ definition of tokens and YYSTYPE. This change is suitable both
+ for previous releases of Bison, and this one.
-* Yacc command and library now available
- The Bison distribution now installs a yacc command, as POSIX requires.
- Also, Bison now installs a small library liby.a containing
- implementations of Yacc-compatible yyerror and main functions.
- This library is normally not useful, but POSIX requires it.
+ If you wish to update, then make sure older version of Bison will
+ fail using `%require "2.2"'.
-* %lex-param, %parse-param
- These now take just one operand, not two.
+* DJGPP support added.
+\f
+Changes in version 2.1, 2005-09-16:
+
+* The C++ lalr1.cc skeleton supports %lex-param.
+
+* Bison-generated parsers now support the translation of diagnostics like
+ "syntax error" into languages other than English. The default
+ language is still English. For details, please see the new
+ Internationalization section of the Bison manual. Software
+ distributors should also see the new PACKAGING file. Thanks to
+ Bruno Haible for this new feature.
+
+* Wording in the Bison-generated parsers has been changed slightly to
+ simplify translation. In particular, the message "memory exhausted"
+ has replaced "parser stack overflow", as the old message was not
+ always accurate for modern Bison-generated parsers.
+
+* Destructors are now called when the parser aborts, for all symbols left
+ behind on the stack. Also, the start symbol is now destroyed after a
+ successful parse. In both cases, the behavior was formerly inconsistent.
+
+* When generating verbose diagnostics, Bison-generated parsers no longer
+ quote the literal strings associated with tokens. For example, for
+ a syntax error associated with '%token NUM "number"' they might
+ print 'syntax error, unexpected number' instead of 'syntax error,
+ unexpected "number"'.
+\f
+Changes in version 2.0, 2004-12-25:
+
+* Possibly-incompatible changes
+
+ - Bison-generated parsers no longer default to using the alloca function
+ (when available) to extend the parser stack, due to widespread
+ problems in unchecked stack-overflow detection. You can "#define
+ YYSTACK_USE_ALLOCA 1" to require the use of alloca, but please read
+ the manual to determine safe values for YYMAXDEPTH in that case.
+
+ - Error token location.
+ During error recovery, the location of the syntax error is updated
+ to cover the whole sequence covered by the error token: it includes
+ the shifted symbols thrown away during the first part of the error
+ recovery, and the lookahead rejected during the second part.
+
+ - Semicolon changes:
+ . Stray semicolons are no longer allowed at the start of a grammar.
+ . Semicolons are now required after in-grammar declarations.
+
+ - Unescaped newlines are no longer allowed in character constants or
+ string literals. They were never portable, and GCC 3.4.0 has
+ dropped support for them. Better diagnostics are now generated if
+ forget a closing quote.
+
+ - NUL bytes are no longer allowed in Bison string literals, unfortunately.
+
+* New features
+
+ - GLR grammars now support locations.
+
+ - New directive: %initial-action.
+ This directive allows the user to run arbitrary code (including
+ initializing @$) from yyparse before parsing starts.
+
+ - A new directive "%expect-rr N" specifies the expected number of
+ reduce/reduce conflicts in GLR parsers.
+
+ - %token numbers can now be hexadecimal integers, e.g., `%token FOO 0x12d'.
+ This is a GNU extension.
+
+ - The option `--report=lookahead' was changed to `--report=look-ahead'.
+ [However, this was changed back after 2.3.]
+
+ - Experimental %destructor support has been added to lalr1.cc.
+
+ - New configure option --disable-yacc, to disable installation of the
+ yacc command and -ly library introduced in 1.875 for POSIX conformance.
+
+* Bug fixes
-* The documentation now emphasizes that yylex and yyerror must be
- declared before use. C99 requires this.
+ - For now, %expect-count violations are now just warnings, not errors.
+ This is for compatibility with Bison 1.75 and earlier (when there are
+ reduce/reduce conflicts) and with Bison 1.30 and earlier (when there
+ are too many or too few shift/reduce conflicts). However, in future
+ versions of Bison we plan to improve the %expect machinery so that
+ these violations will become errors again.
+
+ - Within Bison itself, numbers (e.g., goto numbers) are no longer
+ arbitrarily limited to 16-bit counts.
+
+ - Semicolons are now allowed before "|" in grammar rules, as POSIX requires.
+\f
+Changes in version 1.875, 2003-01-01:
* The documentation license has been upgraded to version 1.2
of the GNU Free Documentation License.
-Changes in version 1.75c, 2002-11-25:
+* syntax error processing
+
+ - In Yacc-style parsers YYLLOC_DEFAULT is now used to compute error
+ locations too. This fixes bugs in error-location computation.
+
+ - %destructor
+ It is now possible to reclaim the memory associated to symbols
+ discarded during error recovery. This feature is still experimental.
+
+ - %error-verbose
+ This new directive is preferred over YYERROR_VERBOSE.
+
+ - #defining yyerror to steal internal variables is discouraged.
+ It is not guaranteed to work forever.
+
+* POSIX conformance
+
+ - Semicolons are once again optional at the end of grammar rules.
+ This reverts to the behavior of Bison 1.33 and earlier, and improves
+ compatibility with Yacc.
-* "parse error" -> "syntax error"
- Bison now uniformly uses the term "syntax error"; formerly, the code
- and manual sometimes used the term "parse error" instead. POSIX
- requires "syntax error" in diagnostics, and it was thought better to
- be consistent.
+ - `parse error' -> `syntax error'
+ Bison now uniformly uses the term `syntax error'; formerly, the code
+ and manual sometimes used the term `parse error' instead. POSIX
+ requires `syntax error' in diagnostics, and it was thought better to
+ be consistent.
-* "parsing stack overflow..." -> "parser stack overflow"
- GLR parsers now report "parser stack overflow" as per the Bison manual.
+ - The documentation now emphasizes that yylex and yyerror must be
+ declared before use. C99 requires this.
-* GLR and inline
- Users of Bison have to decide how they handle the portability of the
- C keyword `inline'.
+ - Bison now parses C99 lexical constructs like UCNs and
+ backslash-newline within C escape sequences, as POSIX 1003.1-2001 requires.
-Changes in version 1.75b, 2002-11-13:
+ - File names are properly escaped in C output. E.g., foo\bar.y is
+ output as "foo\\bar.y".
-* %destructor
- It is now possible to reclaim the memory associated to symbols
- discarded during error recovery. This feature is still experimental.
+ - Yacc command and library now available
+ The Bison distribution now installs a `yacc' command, as POSIX requires.
+ Also, Bison now installs a small library liby.a containing
+ implementations of Yacc-compatible yyerror and main functions.
+ This library is normally not useful, but POSIX requires it.
-* Bison now parses C99 lexical constructs like UCNs and
- backslash-newline within C escape sequences, as POSIX 1003.1-2001 requires.
+ - Type clashes now generate warnings, not errors.
-* --no-line works properly.
+ - If the user does not define YYSTYPE as a macro, Bison now declares it
+ using typedef instead of defining it as a macro.
+ For consistency, YYLTYPE is also declared instead of defined.
-* %error-verbose
- This new directive is preferred over YYERROR_VERBOSE.
+* Other compatibility issues
-* %lex-param, %parse-param
- These new directives are preferred over PARSE_PARAM and LEX_PARAM.
- In addition, they provide a means for yyerror to remain pure, and
- to access to the current location.
+ - %union directives can now have a tag before the `{', e.g., the
+ directive `%union foo {...}' now generates the C code
+ `typedef union foo { ... } YYSTYPE;'; this is for Yacc compatibility.
+ The default union tag is `YYSTYPE', for compatibility with Solaris 9 Yacc.
+ For consistency, YYLTYPE's struct tag is now `YYLTYPE' not `yyltype'.
+ This is for compatibility with both Yacc and Bison 1.35.
- #defining yyerror to steal internal variables is strongly
- discouraged. It is not guaranteed to work for ever.
+ - `;' is output before the terminating `}' of an action, for
+ compatibility with Bison 1.35.
-* #line
- Bison now recognizes #line in its input, and forwards them.
+ - Bison now uses a Yacc-style format for conflict reports, e.g.,
+ `conflicts: 2 shift/reduce, 1 reduce/reduce'.
-* #line
- File names are properly escaped. E.g. foo\bar.y give #line 123 "foo\\bar.y".
+ - `yystype' and `yyltype' are now obsolescent macros instead of being
+ typedefs or tags; they are no longer documented and are planned to be
+ withdrawn in a future release.
-Changes in version 1.75a, 2002-10-24:
+* GLR parser notes
+
+ - GLR and inline
+ Users of Bison have to decide how they handle the portability of the
+ C keyword `inline'.
+
+ - `parsing stack overflow...' -> `parser stack overflow'
+ GLR parsers now report `parser stack overflow' as per the Bison manual.
+
+* Bison now warns if it detects conflicting outputs to the same file,
+ e.g., it generates a warning for `bison -d -o foo.h foo.y' since
+ that command outputs both code and header to foo.h.
+
+* #line in output files
+ - --no-line works properly.
* Bison can no longer be built by a K&R C compiler; it requires C89 or
later to be built. This change originally took place a few versions
ago, but nobody noticed until we recently asked someone to try
building Bison with a K&R C compiler.
-
+\f
Changes in version 1.75, 2002-10-14:
* Bison should now work on 64-bit hosts.
was incorrectly rejected: $1 is defined in the second mid-rule
action, and is equal to the $$ of the first mid-rule action.
-
+\f
Changes in version 1.50, 2002-10-04:
* GLR parsing
allowed some non-error action other than a default reduction on the
error token. The new behavior has long been the documented behavior,
and has long been required by POSIX. For more details, please see
- <http://mail.gnu.org/pipermail/bug-bison/2002-May/001452.html>.
+ Paul Eggert, "Reductions during Bison error handling" (2002-05-20)
+ <http://lists.gnu.org/archive/html/bug-bison/2002-05/msg00038.html>.
* Traces
Popped tokens and nonterminals are now reported.
produces additional information:
- itemset
complete the core item sets with their closure
- - lookahead
- explicitly associate lookaheads to items
+ - lookahead [changed to `look-ahead' in 1.875e through 2.3, but changed back]
+ explicitly associate lookahead tokens to items
- solved
describe shift/reduce conflicts solving.
Bison used to systematically output this information on top of
alloca is used only when compiled with GCC, to avoid portability
problems as on AIX.
+* yyparse now returns 2 if memory is exhausted; formerly it dumped core.
+
* When the generated parser lacks debugging code, YYDEBUG is now 0
(as POSIX requires) instead of being undefined.
-----
-Copyright (C) 2001, 2002 Free Software Foundation, Inc.
+Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
+2004, 2005, 2006 Free Software Foundation, Inc.
-This file is part of GNU Autoconf.
+This file is part of Bison, the GNU Compiler Compiler.
-GNU Autoconf is free software; you can redistribute it and/or modify
+Bison is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
-GNU Autoconf is distributed in the hope that it will be useful,
+Bison is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with autoconf; see the file COPYING. If not, write to
-the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-Boston, MA 02111-1307, USA.
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA.
projects / bison.git / blobdiff