+*** K&C parsers
+
+ Support for generating parsers in K&R C will be removed. Parsers
+ generated for C supprt 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.
+
+** 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 intance, 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.
+
+* 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]
projects / bison.git / blobdiff