Lines Matching full:bison
1 GNU Bison NEWS
27 Caret errors have been added to Bison:
71 for locations. When defined, Bison no longer generates the position.hh
79 This feature was actually introduced, but not documented, in Bison 2.5,
125 We consider compiler warnings about Bison generated parsers to be bugs.
144 Bison 2.6.3's --version was incorrect. This release fixes this issue.
208 Bison no longer executes user-specified M4 code when processing a grammar.
212 In addition to the removal of the features announced in Bison 2.6, the
230 While Bison used to warn about stray $ or @ in action rules, it did not
248 The next major release of Bison will drop support for the following
249 deprecated features. Please report disagreements to bug-bison@gnu.org.
257 *** Features deprecated since Bison 1.875
332 bison generates:
423 With "bison -o lang++/parser.cc", "location.hh" would now include:
442 The "%printer" directive, supported since at least Bison 1.50, is finally
455 ** Building bison:
486 Historically, Yacc and Bison have supported positional references
490 Starting from this version, Bison can also accept named references.
521 Bison can now generate IELR(1) and canonical LR(1) parser tables in
532 of these features, see the new section "Tuning LR" in the Bison
573 See the new section "LAC" in the Bison manual for additional
595 except that the manner in which Bison processes multiple definitions
598 details, see the section "Bison Options" in the Bison manual.
634 Previously, Bison quietly converted all character literals to length
635 one. For example, without warning, Bison interpreted the operators in
642 Bison now warns when a character literal is not of length one. In
643 some future release, Bison will start reporting an error instead.
697 deterministic parsers in C generated by Bison. More recently, it was
698 a documented feature of Bison's experimental Java parsers. As
699 promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
703 being unused, see the Bison 2.4.2 NEWS entry.
707 Previously, Bison appended a semicolon to every user action for
718 As a first step in removing this misfeature, Bison now issues a
719 warning when it appends a semicolon. Moreover, in cases where Bison
724 Bison will cease to append semicolons entirely.
759 the expected token list. Bison's new LAC implementation,
775 *** Bison now properly recognizes the "no-" versions of categories:
777 For example, given the following command line, Bison now enables all
780 bison -Wall,no-yacc gram.y
782 *** Bison now treats S/R and R/R conflicts like other warnings:
784 Previously, conflict reports were independent of Bison's normal
785 warning system. Now, Bison recognizes the warning categories
790 bison -Wno-conflicts-sr gram.y # S/R conflicts not reported
791 bison -Wno-conflicts-rr gram.y # R/R conflicts not reported
792 bison -Wnone gram.y # no conflicts are reported
793 bison -Werror gram.y # any conflict is an error
802 For example, for the following command line, Bison now reports
805 bison -Werror,none,yacc gram.y
807 *** The "none" category now disables all Bison warnings:
809 Previously, the "none" category disabled only Bison warnings for
811 given the following command line, Bison is now guaranteed to
814 bison -Wnone gram.y
818 Since Bison 2.3b, which restored the ability of precedence
828 ** Bison now obeys -Werror and --warnings=error for warnings about
839 ** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
841 errors in Bison 2.5. They will remain warnings, which should be
850 RHEL4, and Tru64 have been addressed. As a result, fatal Bison
858 %token, %left, %right, or %nonassoc. Bison 2.3b and later lost this
861 compatibility with recent Bison releases, it is only a warning for
862 now. In Bison 2.5 and later, it will return to being an error.
864 warning will not be converted to an error in Bison 2.5.]
878 To provide a more flexible alternative, Bison 2.3b introduced the
886 These forms are now considered permanent features of Bison. See the
887 %code entries in the section "Bison Declaration Summary" in the Bison
892 Bison's Java feature as a whole including its current usage of %code
898 deterministic parsers in C generated by Bison. Previously, it was
899 documented for Bison's experimental Java parsers. YYFAIL is no longer
912 http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html
914 The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but
917 Bison features compatible with it. Thus, during parser generation,
918 Bison 2.5 will produce a warning whenever it discovers YYFAIL in a
923 There exists at least one case where Bison 2.5's YYFAIL warning will
925 Bison-defined macros for the sole purpose of suppressing C
927 To avoid Bison's future warning, such YYFAIL uses can be moved to the
928 epilogue (that is, after the second "%%") in the Bison input file. In
929 this release (2.4.2), Bison already generates its own code to suppress
931 phony uses of YYFAIL if compatibility with Bison releases prior to
936 Fix a regression introduced in Bison 2.4: Under some circumstances,
947 Bison used to prepend a trailing semicolon at the end of the user
956 Some grammars still depend on this "feature". Bison 2.4.1 restores
960 behavior to be adjusted. Future releases of Bison will disable this
963 ** A few minor improvements to the Bison manual.
971 modifying its effect on Bison's output file names. Thus, in this release,
991 which has the same effect except that Bison is more careful to warn about
996 Bison can now generate an LALR(1) parser in C with a push interface. That
1005 See the new section "A Push Parser" in the Bison manual for details.
1016 Bison can now generate an LALR(1) parser in Java. The skeleton is
1020 See the new section "Java Parsers" in the Bison manual for details.
1029 that Bison uses, the directive affects the names of the generated files if
1034 Bison can now generate an XML report of the LALR(1) automaton using the new
1044 Bison now employs the terms "useless in grammar" instead of "useless",
1050 Previously, Bison sometimes generated parser tables containing unreachable
1051 states. A state can become unreachable during conflict resolution if Bison
1052 disables a shift action leading to it from a predecessor state. Bison now:
1060 3. For any rule used only in such states, Bison now reports the rule as
1067 See the %define entry in the "Bison Declaration Summary" in the Bison manual
1073 (using "--report=lookahead", for example), Bison now prints each reduction's
1076 of its RHS. Previously, Bison also erroneously printed the lookahead set
1093 Bison 2.3a provided a new set of directives as a more flexible alternative to
1096 the purpose of the code and thus the location(s) where Bison should generate
1104 See the %code entries in section "Bison Declaration Summary" in the Bison
1114 Since Bison 2.2, Bison has warned about mid-rule values that are set but not
1115 used within any of the actions of the parent rule. For example, Bison warns
1120 Now, Bison also warns about mid-rule values that are used but not set. For
1121 example, Bison warns about unset $$ in the mid-rule action in:
1125 However, Bison now disables both of these warnings by default since they
1134 Bison now recognizes two separate kinds of default %destructor's and
1145 Bison no longer supports the "%symbol-default" notation from Bison 2.3a.
1146 "<*>" and "<>" combined achieve the same effect with one exception: Bison no
1154 See the section "Freeing Discarded Symbols" in the Bison manual for further
1158 by POSIX. However, see the end of section "Operator Precedence" in the Bison
1162 completely removed from Bison.
1202 "--yacc", or "%yacc"), Bison no longer generates #define statements for
1205 requires them. Bison still generates an enum for token names in all cases.
1208 potentially incompatible with previous releases of Bison.
1211 "%{ ... %}" syntax. To generate the pre-prologue, Bison concatenates all
1213 the post-prologue, Bison concatenates all prologue blocks that you've
1216 Previous releases of Bison inserted the pre-prologue into both the header
1218 latter case, Bison inserted it only into the code file. For parsers in C++,
1223 Now, Bison never inserts the pre-prologue into the header file. In the code
1226 ** Bison now provides a more flexible alternative to the traditional Yacc
1231 order in which Bison will output these code blocks. However, you are free to
1236 /* Bison treats this block like a pre-prologue block: it inserts it into
1243 /* Bison inserts this block into both the header file and the code file.
1244 * In both files, the point of insertion is before any Bison-generated
1254 /* Bison inserts this block into both the header file and the code file.
1255 * In both files, the point of insertion is after the Bison-generated
1257 * functions or data structures that depend on the Bison-generated
1261 /* Bison treats this block like a post-prologue block: it inserts it into
1265 * Bison-generated definitions. */
1268 If you have multiple occurrences of any one of the above declarations, Bison
1288 ** The distribution terms for all Bison-generated parsers now permit
1290 was granted only for Bison-generated LALR(1) parsers in C.
1296 ** Bison now allows multiple %union declarations, and concatenates
1318 and all, the warnings can be suppressed by letting Bison believe the
1346 ** Bison now warns if it finds a stray "$" or "@" in an action.
1350 in Bison version VERSION or higher.
1361 for previous releases of Bison, and this one.
1363 If you wish to update, then make sure older version of Bison will
1373 ** Bison-generated parsers now support the translation of diagnostics like
1376 Internationalization section of the Bison manual. Software
1380 ** Wording in the Bison-generated parsers has been changed slightly to
1383 always accurate for modern Bison-generated parsers.
1389 ** When generating verbose diagnostics, Bison-generated parsers no longer
1400 - Bison-generated parsers no longer default to using the alloca function
1421 - NUL bytes are no longer allowed in Bison string literals, unfortunately.
1448 This is for compatibility with Bison 1.75 and earlier (when there are
1449 reduce/reduce conflicts) and with Bison 1.30 and earlier (when there
1451 versions of Bison we plan to improve the %expect machinery so that
1454 - Within Bison itself, numbers (e.g., goto numbers) are no longer
1483 This reverts to the behavior of Bison 1.33 and earlier, and improves
1487 Bison now uniformly uses the term "syntax error"; formerly, the code
1495 - Bison now parses C99 lexical constructs like UCNs and
1502 The Bison distribution now installs a "yacc" command, as POSIX requires.
1503 Also, Bison now installs a small library liby.a containing
1509 - If the user does not define YYSTYPE as a macro, Bison now declares it
1520 This is for compatibility with both Yacc and Bison 1.35.
1523 compatibility with Bison 1.35.
1525 - Bison now uses a Yacc-style format for conflict reports, e.g.,
1535 Users of Bison have to decide how they handle the portability of the
1539 GLR parsers now report "parser stack overflow" as per the Bison manual.
1568 ** Bison now warns if it detects conflicting outputs to the same file,
1569 e.g., it generates a warning for "bison -d -o foo.h foo.y" since
1575 ** Bison can no longer be built by a K&R C compiler; it requires C89 or
1578 building Bison with a K&R C compiler.
1583 ** Bison should now work on 64-bit hosts.
1618 causes Bison to produce a Generalized LR (GLR) parser, capable of handling
1623 Unfortunately Bison 1.50 does not work properly on 64-bit hosts
1628 specified, running "bison foo/bar.y" created "foo/bar.c". It
1641 Bison extends this requirement by making it a preference: *if* the
1653 When a Bison-generated parser encounters a syntax error, it now pops
1659 Paul Eggert, "Reductions during Bison error handling" (2002-05-20)
1660 <http://lists.gnu.org/archive/html/bug-bison/2002-05/msg00038.html>.
1672 Bison used to play hacks with the initial rule, which the user does
1677 Before, Bison reported the useless rules, but, although not used,
1695 bison reported both "useful" and "useless" as useless tokens.
1725 bison used to output
1734 In addition to --verbose, bison supports --report=THINGS, which
1742 Bison used to systematically output this information on top of
1755 ** GNU M4 is now required when using Bison.
1761 Some projects use Bison's C parser with C++ compilers, and define
1767 maintain this use. In the future, when Bison has C++ parsers, this
1777 $ bison foo.y -d -o foo.x
1782 Yacc implementations, Bison will mandate this semicolon in the near
1783 future. This eases the implementation of a Bison parser of Bison
1820 Bison dies on incorrect %expectations, we fear there will be
1837 Bison has always permitted actions such as { $$ = $1 }: it adds the
1923 ** The Bison manual is now distributed under the terms of the GNU FDL.
1931 ** Added the old Bison reference card.
1963 ** The make rule which prevented bison.simple from being created on
1969 ** Bison now uses Automake.
1971 ** New mailing lists: <bug-bison@gnu.org> and <help-bison@gnu.org>.
1975 ** Bison honors the TMPDIR environment variable.
1987 ** Errors in the input grammar are not fatal; Bison keeps reading
2002 ** The %raw declaration says to use internal Bison token numbers, not
2034 This file is part of Bison, the GNU Parser Generator.
