+** Future Changes
+
+ The next major release of Bison will drop support for the following
+ deprecated features. Please report disagreements to bug-bison@gnu.org.
+
+*** K&R C parsers
+
+ Support for generating parsers in K&R C will be removed. Parsers
+ generated for C support ISO C90, and are tested with ISO C99 and ISO C11
+ compilers.
+
+*** Features deprecated since Bison 1.875
+
+ The definitions of yystype and yyltype will be removed; use YYSTYPE and
+ YYLTYPE.
+
+ YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and
+ %lex-param, will no longer be supported.
+
+ Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use
+ %error-verbose.
+
+*** The generated header will be included (yacc.c)
+
+ Instead of duplicating the content of the generated header (definition of
+ YYSTYPE, yyparse declaration etc.), the generated parser will include it,
+ as is already the case for GLR or C++ parsers. This change is deferred
+ because existing versions of ylwrap (e.g., Automake 1.12.1) do not support
+ it.
+
+** Generated Parser Headers
+
+*** Guards (yacc.c, glr.c, glr.cc)
+
+ The generated headers are now guarded, as is already the case for C++
+ parsers (lalr1.cc). For instance, with --defines=foo.h:
+
+ #ifndef YY_FOO_H
+ # define YY_FOO_H
+ ...
+ #endif /* !YY_FOO_H */
+
+*** New declarations (yacc.c, glr.c)
+
+ The generated header now declares yydebug and yyparse. Both honor
+ --name-prefix=bar_, and yield
+
+ int bar_parse (void);
+
+ rather than
+
+ #define yyparse bar_parse
+ int yyparse (void);
+
+ in order to facilitate the inclusion of several parser headers inside a
+ single compilation unit.
+
+*** Exported symbols in C++
+
+ The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the
+ header, are removed, as they prevent the possibility of including several
+ generated headers from a single compilation unit.
+
+*** YYLSP_NEEDED
+
+ For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no
+ longer defined.
+
+** New %define variable: api.prefix
+
+ Now that the generated headers are more complete and properly protected
+ against multiple inclusions, constant names, such as YYSTYPE are a
+ problem. While yyparse and others are properly renamed by %name-prefix,
+ YYSTYPE, YYDEBUG and others have never been affected by it. Because it
+ would introduce backward compatibility issues in projects not expecting
+ YYSTYPE to be renamed, instead of changing the behavior of %name-prefix,
+ it is deprecated in favor of a new %define variable: api.prefix.
+
+ The following examples compares both:
+
+ %name-prefix "bar_" | %define api.prefix "bar_"
+ %token <ival> FOO %token <ival> FOO
+ %union { int ival; } %union { int ival; }
+ %% %%
+ exp: 'a'; exp: 'a';
+
+ bison generates:
+
+ #ifndef BAR_FOO_H #ifndef BAR_FOO_H
+ # define BAR_FOO_H # define BAR_FOO_H
+
+ /* Enabling traces. */ /* Enabling traces. */
+ # ifndef YYDEBUG | # ifndef BAR_DEBUG
+ > # if defined YYDEBUG
+ > # if YYDEBUG
+ > # define BAR_DEBUG 1
+ > # else
+ > # define BAR_DEBUG 0
+ > # endif
+ > # else
+ # define YYDEBUG 0 | # define BAR_DEBUG 0
+ > # endif
+ # endif | # endif
+
+ # if YYDEBUG | # if BAR_DEBUG
+ extern int bar_debug; extern int bar_debug;
+ # endif # endif
+
+ /* Tokens. */ /* Tokens. */
+ # ifndef YYTOKENTYPE | # ifndef BAR_TOKENTYPE
+ # define YYTOKENTYPE | # define BAR_TOKENTYPE
+ enum yytokentype { | enum bar_tokentype {
+ FOO = 258 FOO = 258
+ }; };
+ # endif # endif
+
+ #if ! defined YYSTYPE \ | #if ! defined BAR_STYPE \
+ && ! defined YYSTYPE_IS_DECLARED | && ! defined BAR_STYPE_IS_DECLARED
+ typedef union YYSTYPE | typedef union BAR_STYPE
+ { {
+ int ival; int ival;
+ } YYSTYPE; | } BAR_STYPE;
+ # define YYSTYPE_IS_DECLARED 1 | # define BAR_STYPE_IS_DECLARED 1
+ #endif #endif
+
+ extern YYSTYPE bar_lval; | extern BAR_STYPE bar_lval;
+
+ int bar_parse (void); int bar_parse (void);
+
+ #endif /* !BAR_FOO_H */ #endif /* !BAR_FOO_H */
+
+* Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
+
+** Future changes:
+
+ The next major release will drop support for generating parsers in K&R C.
+
+** yacc.c: YYBACKUP works as expected.
+
+** glr.c improvements:
+
+*** Location support is eliminated when not requested:
+
+ GLR parsers used to include location-related code even when locations were
+ not requested, and therefore not even usable.
+
+*** __attribute__ is preserved:
+
+ __attribute__ is no longer disabled when __STRICT_ANSI__ is defined (i.e.,
+ when -std is passed to GCC).
+
+** lalr1.java: several fixes:
+
+ The Java parser no longer throws ArrayIndexOutOfBoundsException if the
+ first token leads to a syntax error. Some minor clean ups.
+
+** Changes for C++:
+
+*** C++11 compatibility:
+
+ C and C++ parsers use "nullptr" instead of "0" when __cplusplus is 201103L
+ or higher.
+
+*** Header guards
+
+ The header files such as "parser.hh", "location.hh", etc. used a constant
+ name for preprocessor guards, for instance:
+
+ #ifndef BISON_LOCATION_HH
+ # define BISON_LOCATION_HH
+ ...
+ #endif // !BISON_LOCATION_HH
+
+ The inclusion guard is now computed from "PREFIX/FILE-NAME", where lower
+ case characters are converted to upper case, and series of
+ non-alphanumerical characters are converted to an underscore.
+
+ With "bison -o lang++/parser.cc", "location.hh" would now include:
+
+ #ifndef YY_LANG_LOCATION_HH
+ # define YY_LANG_LOCATION_HH
+ ...
+ #endif // !YY_LANG_LOCATION_HH
+
+*** C++ locations:
+
+ The position and location constructors (and their initialize methods)
+ accept new arguments for line and column. Several issues in the
+ documentation were fixed.
+
+** liby is no longer asking for "rpl_fprintf" on some platforms.
+
+** Changes in the manual:
+
+*** %printer is documented
+
+ The "%printer" directive, supported since at least Bison 1.50, is finally
+ documented. The "mfcalc" example is extended to demonstrate it.
+
+ For consistency with the C skeletons, the C++ parsers now also support
+ "yyoutput" (as an alias to "debug_stream ()").
+
+*** Several improvements have been made:
+
+ The layout for grammar excerpts was changed to a more compact scheme.
+ Named references are motivated. The description of the automaton
+ description file (*.output) is updated to the current format. Incorrect
+ index entries were fixed. Some other errors were fixed.
+
+** Building bison:
+
+*** Conflicting prototypes with recent/modified Flex.
+
+ Fixed build problems with the current, unreleased, version of Flex, and
+ some modified versions of 2.5.35, which have modified function prototypes.
+
+*** Warnings during the build procedure have been eliminated.
+
+*** Several portability problems in the test suite have been fixed:
+
+ This includes warnings with some compilers, unexpected behavior of tools
+ such as diff, warning messages from the test suite itself, etc.
+
+*** The install-pdf target works properly:
+
+ Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
+ halts in the middle of its course.
+
+* Changes in version 2.5 (2011-05-14):
+
+** Grammar symbol names can now contain non-initial dashes:
+
+ Consistently with directives (such as %error-verbose) and with
+ %define variables (e.g. push-pull), grammar symbol names may contain
+ dashes in any position except the beginning. This is a GNU
+ extension over POSIX Yacc. Thus, use of this extension is reported
+ by -Wyacc and rejected in Yacc mode (--yacc).
+
+** Named references:
+
+ Historically, Yacc and Bison have supported positional references
+ ($n, $$) to allow access to symbol values from inside of semantic
+ actions code.
+
+ Starting from this version, Bison can also accept named references.
+ When no ambiguity is possible, original symbol names may be used
+ as named references:
+
+ if_stmt : "if" cond_expr "then" then_stmt ';'
+ { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }
+
+ In the more common case, explicit names may be declared:
+
+ stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
+ { $res = mk_if_stmt($cond, $then, $else); }
+
+ Location information is also accessible using @name syntax. When
+ accessing symbol names containing dots or dashes, explicit bracketing
+ ($[sym.1]) must be used.
+
+ These features are experimental in this version. More user feedback
+ will help to stabilize them.
+
+** IELR(1) and canonical LR(1):
+
+ IELR(1) is a minimal LR(1) parser table generation algorithm. That
+ is, given any context-free grammar, IELR(1) generates parser tables
+ with the full language-recognition power of canonical LR(1) but with
+ nearly the same number of parser states as LALR(1). This reduction
+ in parser states is often an order of magnitude. More importantly,
+ because canonical LR(1)'s extra parser states may contain duplicate
+ conflicts in the case of non-LR(1) grammars, the number of conflicts
+ for IELR(1) is often an order of magnitude less as well. This can
+ significantly reduce the complexity of developing of a grammar.
+
+ Bison can now generate IELR(1) and canonical LR(1) parser tables in
+ place of its traditional LALR(1) parser tables, which remain the
+ default. You can specify the type of parser tables in the grammar
+ file with these directives:
+
+ %define lr.type lalr
+ %define lr.type ielr
+ %define lr.type canonical-lr
+
+ The default-reduction optimization in the parser tables can also be
+ adjusted using "%define lr.default-reductions". For details on both
+ of these features, see the new section "Tuning LR" in the Bison
+ manual.
+
+ These features are experimental. More user feedback will help to
+ stabilize them.
+
+** LAC (Lookahead Correction) for syntax error handling:
+
+ Canonical LR, IELR, and LALR can suffer from a couple of problems
+ upon encountering a syntax error. First, the parser might perform
+ additional parser stack reductions before discovering the syntax
+ error. Such reductions can perform user semantic actions that are
+ unexpected because they are based on an invalid token, and they
+ cause error recovery to begin in a different syntactic context than
+ the one in which the invalid token was encountered. Second, when
+ verbose error messages are enabled (with %error-verbose or the
+ obsolete "#define YYERROR_VERBOSE"), the expected token list in the
+ syntax error message can both contain invalid tokens and omit valid
+ tokens.
+
+ The culprits for the above problems are %nonassoc, default
+ reductions in inconsistent states, and parser state merging. Thus,
+ IELR and LALR suffer the most. Canonical LR can suffer only if
+ %nonassoc is used or if default reductions are enabled for
+ inconsistent states.
+
+ LAC is a new mechanism within the parsing algorithm that solves
+ these problems for canonical LR, IELR, and LALR without sacrificing
+ %nonassoc, default reductions, or state merging. When LAC is in
+ use, canonical LR and IELR behave almost exactly the same for both
+ syntactically acceptable and syntactically unacceptable input.
+ While LALR still does not support the full language-recognition
+ power of canonical LR and IELR, LAC at least enables LALR's syntax
+ error handling to correctly reflect LALR's language-recognition
+ power.
+
+ Currently, LAC is only supported for deterministic parsers in C.
+ You can enable LAC with the following directive:
+
+ %define parse.lac full
+
+ See the new section "LAC" in the Bison manual for additional
+ details including a few caveats.
+
+ LAC is an experimental feature. More user feedback will help to
+ stabilize it.
+
+** %define improvements:
+
+*** Can now be invoked via the command line:
+
+ Each of these command-line options
+
+ -D NAME[=VALUE]
+ --define=NAME[=VALUE]
+
+ -F NAME[=VALUE]
+ --force-define=NAME[=VALUE]
+
+ is equivalent to this grammar file declaration
+
+ %define NAME ["VALUE"]
+
+ except that the manner in which Bison processes multiple definitions
+ for the same NAME differs. Most importantly, -F and --force-define
+ quietly override %define, but -D and --define do not. For further
+ details, see the section "Bison Options" in the Bison manual.
+
+*** Variables renamed:
+
+ The following %define variables
+
+ api.push_pull
+ lr.keep_unreachable_states
+
+ have been renamed to
+
+ api.push-pull
+ lr.keep-unreachable-states
+
+ The old names are now deprecated but will be maintained indefinitely
+ for backward compatibility.
+
+*** Values no longer need to be quoted in the grammar file:
+
+ If a %define value is an identifier, it no longer needs to be placed
+ within quotations marks. For example,
+
+ %define api.push-pull "push"
+
+ can be rewritten as
+
+ %define api.push-pull push
+
+*** Unrecognized variables are now errors not warnings.
+
+*** Multiple invocations for any variable is now an error not a warning.
+
+** Unrecognized %code qualifiers are now errors not warnings.
+
+** Character literals not of length one:
+
+ Previously, Bison quietly converted all character literals to length
+ one. For example, without warning, Bison interpreted the operators in
+ the following grammar to be the same token:
+
+ exp: exp '++'
+ | exp '+' exp
+ ;
+
+ Bison now warns when a character literal is not of length one. In
+ some future release, Bison will start reporting an error instead.
+
+** Destructor calls fixed for lookaheads altered in semantic actions:
+
+ Previously for deterministic parsers in C, if a user semantic action
+ altered yychar, the parser in some cases used the old yychar value to
+ determine which destructor to call for the lookahead upon a syntax
+ error or upon parser return. This bug has been fixed.
+
+** C++ parsers use YYRHSLOC:
+
+ Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
+ macro and use it in the default YYLLOC_DEFAULT. You are encouraged
+ to use it. If, for instance, your location structure has "first"
+ and "last" members, instead of
+
+ # define YYLLOC_DEFAULT(Current, Rhs, N) \
+ do \
+ if (N) \
+ { \
+ (Current).first = (Rhs)[1].location.first; \
+ (Current).last = (Rhs)[N].location.last; \
+ } \
+ else \
+ { \
+ (Current).first = (Current).last = (Rhs)[0].location.last; \
+ } \
+ while (false)
+
+ use:
+
+ # define YYLLOC_DEFAULT(Current, Rhs, N) \
+ do \
+ if (N) \
+ { \
+ (Current).first = YYRHSLOC (Rhs, 1).first; \
+ (Current).last = YYRHSLOC (Rhs, N).last; \
+ } \
+ else \
+ { \
+ (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last; \
+ } \
+ while (false)
+
+** YYLLOC_DEFAULT in C++:
+
+ The default implementation of YYLLOC_DEFAULT used to be issued in
+ the header file. It is now output in the implementation file, after
+ the user %code sections so that its #ifndef guard does not try to
+ override the user's YYLLOC_DEFAULT if provided.
+
+** YYFAIL now produces warnings and Java parsers no longer implement it:
+
+ YYFAIL has existed for many years as an undocumented feature of
+ deterministic parsers in C generated by Bison. More recently, it was
+ a documented feature of Bison's experimental Java parsers. As
+ promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
+ semantic action now produces a deprecation warning, and Java parsers
+ no longer implement YYFAIL at all. For further details, including a
+ discussion of how to suppress C preprocessor warnings about YYFAIL
+ being unused, see the Bison 2.4.2 NEWS entry.
+
+** Temporary hack for adding a semicolon to the user action:
+
+ Previously, Bison appended a semicolon to every user action for
+ reductions when the output language defaulted to C (specifically, when
+ neither %yacc, %language, %skeleton, or equivalent command-line
+ options were specified). This allowed actions such as
+
+ exp: exp "+" exp { $$ = $1 + $3 };
+
+ instead of
+
+ exp: exp "+" exp { $$ = $1 + $3; };
+
+ As a first step in removing this misfeature, Bison now issues a
+ warning when it appends a semicolon. Moreover, in cases where Bison
+ cannot easily determine whether a semicolon is needed (for example, an
+ action ending with a cpp directive or a braced compound initializer),
+ it no longer appends one. Thus, the C compiler might now complain
+ about a missing semicolon where it did not before. Future releases of
+ Bison will cease to append semicolons entirely.
+
+** Verbose syntax error message fixes:
+
+ When %error-verbose or the obsolete "#define YYERROR_VERBOSE" is
+ specified, syntax error messages produced by the generated parser
+ include the unexpected token as well as a list of expected tokens.
+ The effect of %nonassoc on these verbose messages has been corrected
+ in two ways, but a more complete fix requires LAC, described above:
+
+*** When %nonassoc is used, there can exist parser states that accept no
+ tokens, and so the parser does not always require a lookahead token
+ in order to detect a syntax error. Because no unexpected token or
+ expected tokens can then be reported, the verbose syntax error
+ message described above is suppressed, and the parser instead
+ reports the simpler message, "syntax error". Previously, this
+ suppression was sometimes erroneously triggered by %nonassoc when a
+ lookahead was actually required. Now verbose messages are
+ suppressed only when all previous lookaheads have already been
+ shifted or discarded.
+
+*** Previously, the list of expected tokens erroneously included tokens
+ that would actually induce a syntax error because conflicts for them
+ were resolved with %nonassoc in the current parser state. Such
+ tokens are now properly omitted from the list.
+
+*** Expected token lists are still often wrong due to state merging
+ (from LALR or IELR) and default reductions, which can both add
+ invalid tokens and subtract valid tokens. Canonical LR almost
+ completely fixes this problem by eliminating state merging and
+ default reductions. However, there is one minor problem left even
+ when using canonical LR and even after the fixes above. That is,
+ if the resolution of a conflict with %nonassoc appears in a later
+ parser state than the one at which some syntax error is
+ discovered, the conflicted token is still erroneously included in
+ the expected token list. Bison's new LAC implementation,
+ described above, eliminates this problem and the need for
+ canonical LR. However, LAC is still experimental and is disabled
+ by default.
+
+** Java skeleton fixes:
+
+*** A location handling bug has been fixed.
+
+*** The top element of each of the value stack and location stack is now
+ cleared when popped so that it can be garbage collected.
+
+*** Parser traces now print the top element of the stack.
+
+** -W/--warnings fixes:
+
+*** Bison now properly recognizes the "no-" versions of categories:
+
+ For example, given the following command line, Bison now enables all
+ warnings except warnings for incompatibilities with POSIX Yacc:
+
+ bison -Wall,no-yacc gram.y
+
+*** Bison now treats S/R and R/R conflicts like other warnings:
+
+ Previously, conflict reports were independent of Bison's normal
+ warning system. Now, Bison recognizes the warning categories
+ "conflicts-sr" and "conflicts-rr". This change has important
+ consequences for the -W and --warnings command-line options. For
+ example:
+
+ bison -Wno-conflicts-sr gram.y # S/R conflicts not reported
+ bison -Wno-conflicts-rr gram.y # R/R conflicts not reported
+ bison -Wnone gram.y # no conflicts are reported
+ bison -Werror gram.y # any conflict is an error
+
+ However, as before, if the %expect or %expect-rr directive is
+ specified, an unexpected number of conflicts is an error, and an
+ expected number of conflicts is not reported, so -W and --warning
+ then have no effect on the conflict report.
+
+*** The "none" category no longer disables a preceding "error":
+
+ For example, for the following command line, Bison now reports
+ errors instead of warnings for incompatibilities with POSIX Yacc:
+
+ bison -Werror,none,yacc gram.y
+
+*** The "none" category now disables all Bison warnings:
+
+ Previously, the "none" category disabled only Bison warnings for
+ which there existed a specific -W/--warning category. However,
+ given the following command line, Bison is now guaranteed to
+ suppress all warnings:
+
+ bison -Wnone gram.y
+
+** Precedence directives can now assign token number 0:
+
+ Since Bison 2.3b, which restored the ability of precedence
+ directives to assign token numbers, doing so for token number 0 has
+ produced an assertion failure. For example:
+
+ %left END 0
+
+ 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
projects / bison.git / blobdiff