+ This bug has been fixed.
+
+* Changes in version 2.4.3 (2010-08-05):
+
+** Bison now obeys -Werror and --warnings=error for warnings about
+ grammar rules that are useless in the parser due to conflicts.
+
+** Problems with spawning M4 on at least FreeBSD 8 and FreeBSD 9 have
+ been fixed.
+
+** Failures in the test suite for GCC 4.5 have been fixed.
+
+** Failures in the test suite for some versions of Sun Studio C++ have
+ been fixed.
+
+** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
+ warnings about undefined %prec identifiers will not be converted to
+ errors in Bison 2.5. They will remain warnings, which should be
+ sufficient for POSIX while avoiding backward compatibility issues.
+
+** Minor documentation fixes.
+
+* Changes in version 2.4.2 (2010-03-20):
+
+** Some portability problems that resulted in failures and livelocks
+ in the test suite on some versions of at least Solaris, AIX, HP-UX,
+ RHEL4, and Tru64 have been addressed. As a result, fatal Bison
+ errors should no longer cause M4 to report a broken pipe on the
+ affected platforms.
+
+** "%prec IDENTIFIER" requires IDENTIFIER to be defined separately.
+
+ POSIX specifies that an error be reported for any identifier that does
+ not appear on the LHS of a grammar rule and that is not defined by
+ %token, %left, %right, or %nonassoc. Bison 2.3b and later lost this
+ error report for the case when an identifier appears only after a
+ %prec directive. It is now restored. However, for backward
+ compatibility with recent Bison releases, it is only a warning for
+ now. In Bison 2.5 and later, it will return to being an error.
+ [Between the 2.4.2 and 2.4.3 releases, it was decided that this
+ warning will not be converted to an error in Bison 2.5.]
+
+** Detection of GNU M4 1.4.6 or newer during configure is improved.
+
+** Warnings from gcc's -Wundef option about undefined YYENABLE_NLS,
+ YYLTYPE_IS_TRIVIAL, and __STRICT_ANSI__ in C/C++ parsers are now
+ avoided.
+
+** %code is now a permanent feature.
+
+ A traditional Yacc prologue directive is written in the form:
+
+ %{CODE%}
+
+ To provide a more flexible alternative, Bison 2.3b introduced the
+ %code directive with the following forms for C/C++:
+
+ %code {CODE}
+ %code requires {CODE}
+ %code provides {CODE}
+ %code top {CODE}
+
+ These forms are now considered permanent features of Bison. See the
+ %code entries in the section "Bison Declaration Summary" in the Bison
+ manual for a summary of their functionality. See the section
+ "Prologue Alternatives" for a detailed discussion including the
+ advantages of %code over the traditional Yacc prologue directive.
+
+ Bison's Java feature as a whole including its current usage of %code
+ is still considered experimental.
+
+** YYFAIL is deprecated and will eventually be removed.
+
+ YYFAIL has existed for many years as an undocumented feature of
+ deterministic parsers in C generated by Bison. Previously, it was
+ documented for Bison's experimental Java parsers. YYFAIL is no longer
+ documented for Java parsers and is formally deprecated in both cases.
+ Users are strongly encouraged to migrate to YYERROR, which is
+ specified by POSIX.
+
+ Like YYERROR, you can invoke YYFAIL from a semantic action in order to
+ induce a syntax error. The most obvious difference from YYERROR is
+ that YYFAIL will automatically invoke yyerror to report the syntax
+ error so that you don't have to. However, there are several other
+ subtle differences between YYERROR and YYFAIL, and YYFAIL suffers from
+ inherent flaws when %error-verbose or "#define YYERROR_VERBOSE" is
+ used. For a more detailed discussion, see:
+
+ http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html
+
+ The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but
+ deterministic parsers in C will continue to implement it. However,
+ because YYFAIL is already flawed, it seems futile to try to make new
+ Bison features compatible with it. Thus, during parser generation,
+ Bison 2.5 will produce a warning whenever it discovers YYFAIL in a
+ rule action. In a later release, YYFAIL will be disabled for
+ %error-verbose and "#define YYERROR_VERBOSE". Eventually, YYFAIL will
+ be removed altogether.
+
+ There exists at least one case where Bison 2.5's YYFAIL warning will
+ be a false positive. Some projects add phony uses of YYFAIL and other
+ Bison-defined macros for the sole purpose of suppressing C
+ preprocessor warnings (from GCC cpp's -Wunused-macros, for example).
+ To avoid Bison's future warning, such YYFAIL uses can be moved to the
+ epilogue (that is, after the second "%%") in the Bison input file. In
+ this release (2.4.2), Bison already generates its own code to suppress
+ C preprocessor warnings for YYFAIL, so projects can remove their own
+ phony uses of YYFAIL if compatibility with Bison releases prior to
+ 2.4.2 is not necessary.
+
+** Internationalization.
+
+ Fix a regression introduced in Bison 2.4: Under some circumstances,
+ message translations were not installed although supported by the
+ host system.
+
+* Changes in version 2.4.1 (2008-12-11):
+
+** In the GLR defines file, unexpanded M4 macros in the yylval and yylloc
+ declarations have been fixed.
+
+** Temporary hack for adding a semicolon to the user action.
+
+ Bison used to prepend a trailing semicolon at the end of the user
+ action for reductions. This allowed actions such as
+
+ exp: exp "+" exp { $$ = $1 + $3 };
+
+ instead of
+
+ exp: exp "+" exp { $$ = $1 + $3; };
+
+ Some grammars still depend on this "feature". Bison 2.4.1 restores
+ the previous behavior in the case of C output (specifically, when
+ neither %language or %skeleton or equivalent command-line options
+ are used) to leave more time for grammars depending on the old
+ behavior to be adjusted. Future releases of Bison will disable this
+ feature.
+
+** A few minor improvements to the Bison manual.
+
+* Changes in version 2.4 (2008-11-02):
+
+** %language is an experimental feature.
+
+ We first introduced this feature in test release 2.3b as a cleaner
+ alternative to %skeleton. Since then, we have discussed the possibility of
+ modifying its effect on Bison's output file names. Thus, in this release,
+ we consider %language to be an experimental feature that will likely evolve
+ in future releases.
+
+** Forward compatibility with GNU M4 has been improved.
+
+** Several bugs in the C++ skeleton and the experimental Java skeleton have been
+ fixed.
+
+* Changes in version 2.3b (2008-05-27):
+
+** The quotes around NAME that used to be required in the following directive
+ are now deprecated:
+
+ %define NAME "VALUE"
+
+** The directive "%pure-parser" is now deprecated in favor of:
+
+ %define api.pure
+
+ which has the same effect except that Bison is more careful to warn about
+ unreasonable usage in the latter case.
+
+** Push Parsing
+
+ Bison can now generate an LALR(1) parser in C with a push interface. That
+ is, instead of invoking "yyparse", which pulls tokens from "yylex", you can
+ push one token at a time to the parser using "yypush_parse", which will
+ return to the caller after processing each token. By default, the push
+ interface is disabled. Either of the following directives will enable it:
+
+ %define api.push_pull "push" // Just push; does not require yylex.
+ %define api.push_pull "both" // Push and pull; requires yylex.
+
+ See the new section "A Push Parser" in the Bison manual for details.
+
+ The current push parsing interface is experimental and may evolve. More user
+ feedback will help to stabilize it.
+
+** The -g and --graph options now output graphs in Graphviz DOT format,
+ not VCG format. Like --graph, -g now also takes an optional FILE argument
+ and thus cannot be bundled with other short options.
+
+** Java
+
+ Bison can now generate an LALR(1) parser in Java. The skeleton is
+ "data/lalr1.java". Consider using the new %language directive instead of
+ %skeleton to select it.
+
+ See the new section "Java Parsers" in the Bison manual for details.
+
+ The current Java interface is experimental and may evolve. More user
+ feedback will help to stabilize it.
+
+** %language
+
+ This new directive specifies the programming language of the generated
+ parser, which can be C (the default), C++, or Java. Besides the skeleton
+ that Bison uses, the directive affects the names of the generated files if
+ the grammar file's name ends in ".y".
+
+** XML Automaton Report
+
+ Bison can now generate an XML report of the LALR(1) automaton using the new
+ "--xml" option. The current XML schema is experimental and may evolve. More
+ user feedback will help to stabilize it.
+
+** The grammar file may now specify the name of the parser header file using
+ %defines. For example:
+
+ %defines "parser.h"
+
+** When reporting useless rules, useless nonterminals, and unused terminals,
+ Bison now employs the terms "useless in grammar" instead of "useless",
+ "useless in parser" instead of "never reduced", and "unused in grammar"
+ instead of "unused".
+
+** Unreachable State Removal
+
+ Previously, Bison sometimes generated parser tables containing unreachable
+ states. A state can become unreachable during conflict resolution if Bison
+ disables a shift action leading to it from a predecessor state. Bison now:
+
+ 1. Removes unreachable states.
+
+ 2. Does not report any conflicts that appeared in unreachable states.
+ WARNING: As a result, you may need to update %expect and %expect-rr
+ directives in existing grammar files.
+
+ 3. For any rule used only in such states, Bison now reports the rule as
+ "useless in parser due to conflicts".
+
+ This feature can be disabled with the following directive:
+
+ %define lr.keep_unreachable_states
+
+ See the %define entry in the "Bison Declaration Summary" in the Bison manual
+ for further discussion.
+
+** Lookahead Set Correction in the ".output" Report
+
+ When instructed to generate a ".output" file including lookahead sets
+ (using "--report=lookahead", for example), Bison now prints each reduction's
+ lookahead set only next to the associated state's one item that (1) is
+ associated with the same rule as the reduction and (2) has its dot at the end
+ of its RHS. Previously, Bison also erroneously printed the lookahead set
+ next to all of the state's other items associated with the same rule. This
+ bug affected only the ".output" file and not the generated parser source
+ code.
+
+** --report-file=FILE is a new option to override the default ".output" file
+ name.
+
+** The "=" that used to be required in the following directives is now
+ deprecated:
+
+ %file-prefix "parser"
+ %name-prefix "c_"
+ %output "parser.c"
+
+** An Alternative to "%{...%}" -- "%code QUALIFIER {CODE}"
+
+ Bison 2.3a provided a new set of directives as a more flexible alternative to
+ the traditional Yacc prologue blocks. Those have now been consolidated into
+ a single %code directive with an optional qualifier field, which identifies
+ the purpose of the code and thus the location(s) where Bison should generate
+ it:
+
+ 1. "%code {CODE}" replaces "%after-header {CODE}"
+ 2. "%code requires {CODE}" replaces "%start-header {CODE}"
+ 3. "%code provides {CODE}" replaces "%end-header {CODE}"
+ 4. "%code top {CODE}" replaces "%before-header {CODE}"
+
+ See the %code entries in section "Bison Declaration Summary" in the Bison
+ manual for a summary of the new functionality. See the new section "Prologue
+ Alternatives" for a detailed discussion including the advantages of %code
+ over the traditional Yacc prologues.
+
+ The prologue alternatives are experimental. More user feedback will help to
+ determine whether they should become permanent features.
+
+** Revised warning: unset or unused mid-rule values
+
+ Since Bison 2.2, Bison has warned about mid-rule values that are set but not
+ used within any of the actions of the parent rule. For example, Bison warns
+ about unused $2 in:
+
+ exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };
+
+ Now, Bison also warns about mid-rule values that are used but not set. For
+ example, Bison warns about unset $$ in the mid-rule action in:
+
+ exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };
+
+ However, Bison now disables both of these warnings by default since they
+ sometimes prove to be false alarms in existing grammars employing the Yacc
+ constructs $0 or $-N (where N is some positive integer).
+
+ To enable these warnings, specify the option "--warnings=midrule-values" or
+ "-W", which is a synonym for "--warnings=all".
+
+** Default %destructor or %printer with "<*>" or "<>"
+
+ Bison now recognizes two separate kinds of default %destructor's and
+ %printer's:
+
+ 1. Place "<*>" in a %destructor/%printer symbol list to define a default
+ %destructor/%printer for all grammar symbols for which you have formally
+ declared semantic type tags.
+
+ 2. Place "<>" in a %destructor/%printer symbol list to define a default
+ %destructor/%printer for all grammar symbols without declared semantic
+ type tags.
+
+ Bison no longer supports the "%symbol-default" notation from Bison 2.3a.
+ "<*>" and "<>" combined achieve the same effect with one exception: Bison no
+ longer applies any %destructor to a mid-rule value if that mid-rule value is
+ not actually ever referenced using either $$ or $n in a semantic action.
+
+ The default %destructor's and %printer's are experimental. More user
+ feedback will help to determine whether they should become permanent
+ features.
+
+ See the section "Freeing Discarded Symbols" in the Bison manual for further
+ details.
+
+** %left, %right, and %nonassoc can now declare token numbers. This is required
+ by POSIX. However, see the end of section "Operator Precedence" in the Bison
+ manual for a caveat concerning the treatment of literal strings.
+
+** The nonfunctional --no-parser, -n, and %no-parser options have been
+ completely removed from Bison.
+
+* 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.
+
+ [Although we failed to mention this here in the 2.3a release, the default
+ %destructor's and %printer's were experimental, and they were rewritten in
+ future versions.]
+
+** 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.
+
+ [Although we failed to mention this here in the 2.3a release, the prologue
+ alternatives were experimental, and they were rewritten in future versions.]
+
+** 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.
+
+** 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.
+
+ 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.
+
+ If you wish to update, then make sure older version of Bison will
+ fail using '%require "2.2"'.
+
+** 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
+
+ - 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.
projects / bison.git / blobdiff