3 * Noteworthy changes in release ?.? (????-??-??) [?]
7 It is always recommended to prefer `%define api.value.type foo` to
8 `#define YYSTYPE foo`. The latter is supported in C for compatibility
9 with Yacc, but not in C++. Warnings are now issued if `#define YYSTYPE`
10 is used in C++, and eventually support will be removed.
12 Support for the YYPRINT macro is removed. It worked only with yacc.c and
13 only for tokens. It was obsoleted by %printer, introduced in Bison 1.50
20 In conformance with the recommendations of the Graphviz team
21 (https://marc.info/?l=graphviz-devel&m=129418103126092), `-g`/`--graph`
22 now generates a *.gv file by default, instead of *.dot. A transition
27 Prefer value_type to semantic_type to denote the semantic value type,
28 specified by the `api.value.type` %define variable.
32 There were no debug traces for deferred calls to user actions. They are
37 *** Option -H, --header and directive %header
39 The option `-H`/`--header` supersedes the option `--defines`, and the
40 directive %header supersedes %defines. Both `--defines` and `%defines`
41 are, of course, maintained for backward compatibility.
45 Since version 2.4 Bison can be used to generate HTML reports. However it
46 was a two-step process: first bison must be invoked with option `--xml`,
47 and then xsltproc must be run to the convert the XML reports into HTML.
49 The new option `--html` combines these steps. The xsltproc program must
52 *** A C++ native GLR parser
54 A new version of the generated C++ GLR parser was added as "glr2.cc". It
55 is forked from the existing glr.c/cc parser, with the objective of making
56 it a more modern, truly C++ parser (instead of a C++ wrapper around a C
57 parser). Down the line, the goal is to support `%define api.value.type
58 variant` and maybe share code with lalr1.cc.
60 The current parser should be identical in terms of interface, functionality
61 and performance to "glr.cc". To try it out, simply use
67 Counterexamples now show the rule numbers, and always show ε for rules
68 with an empty right-hand side. For instance
80 *** Lookahead correction in Java
82 The Java skeleton (lalr1.java) now supports LAC, via the `parse.lac`
85 *** Abort parsing for memory exhaustion (C)
87 User actions may now use `YYNOMEM` (similar to `YYACCEPT` and `YYABORT`)
88 to abort the current parse with memory exhaustion.
90 *** Printing locations in debug traces (C)
92 The `YYLOCATION_PRINT(File, Loc)` macro prints a location. It is defined
93 when (i) locations are enabled, (ii) the default type for locations is
94 used, (iii) debug traces are enabled, and (iv) `YYLOCATION_PRINT` is not
97 Users may define `YYLOCATION_PRINT` to cover other cases.
100 * Noteworthy changes in release 3.7.5 (2021-01-24) [stable]
104 *** Counterexample Generation
106 In some cases counterexample generation could crash. This is fixed.
108 *** Fix Table Generation
110 In some very rare conditions, when there are many useless tokens, it was
111 possible to generate incorrect parsers.
113 *** GLR parsers now support %merge together with api.value.type=union.
115 *** C++ parsers use noexcept in more places.
117 *** Generated parsers avoid some warnings about signedness issues.
119 *** C-language parsers now avoid warnings from pedantic clang.
121 *** C-language parsers now work around quirks of HP-UX 11.23 (2003).
124 * Noteworthy changes in release 3.7.4 (2020-11-14) [stable]
128 *** Bug fixes in yacc.c
130 In Yacc mode, all the tokens are defined twice: once as an enum, and then
131 as a macro. YYEMPTY was missing its macro.
133 *** Bug fixes in lalr1.cc
135 The lalr1.cc skeleton used to emit internal assertions (using YY_ASSERT)
136 even when the `parse.assert` %define variable is not enabled. It no
139 The private internal macro YY_ASSERT now obeys the `api.prefix` %define
142 When there is a very large number of tokens, some assertions could be long
143 enough to hit arbitrary limits in Visual C++. They have been rewritten to
144 work around this limitation.
148 The YYBISON macro in generated "regular C parsers" (from the "yacc.c"
149 skeleton) used to be defined to 1. It is now defined to the version of
150 Bison as an integer (e.g., 30704 for version 3.7.4).
153 * Noteworthy changes in release 3.7.3 (2020-10-13) [stable]
157 Fix concurrent build issues.
159 The bison executable is no longer linked uselessly against libreadline.
161 Fix incorrect use of yytname in glr.cc.
164 * Noteworthy changes in release 3.7.2 (2020-09-05) [stable]
166 This release of Bison fixes all known bugs reported for Bison in MITRE's
167 Common Vulnerabilities and Exposures (CVE) system. These vulnerabilities
168 are only about bison-the-program itself, not the generated code.
170 Although these bugs are typically irrelevant to how Bison is used, they
171 are worth fixing if only to give users peace of mind.
173 There is no known vulnerability in the generated parsers.
177 Fix concurrent build issues (introduced in Bison 3.5).
179 Push parsers always use YYMALLOC/YYFREE (no direct calls to malloc/free).
181 Fix portability issues of the test suite, and of bison itself.
183 Some unlikely crashes found by fuzzing have been fixed. This is only
184 about bison itself, not the generated parsers.
187 * Noteworthy changes in release 3.7.1 (2020-08-02) [stable]
191 Crash when a token alias contains a NUL byte.
193 Portability issues with libtextstyle.
195 Portability issues of Bison itself with MSVC.
199 Improvements and fixes in the documentation.
201 More precise location about symbol type redefinitions.
204 * Noteworthy changes in release 3.7 (2020-07-23) [stable]
206 ** Deprecated features
208 The YYPRINT macro, which works only with yacc.c and only for tokens, was
209 obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
210 It is deprecated and its support will be removed eventually.
212 In conformance with the recommendations of the Graphviz team, in the next
213 version Bison the option `--graph` will generate a *.gv file by default,
214 instead of *.dot. A transition started in Bison 3.4.
218 *** Counterexample Generation
220 Contributed by Vincent Imbimbo.
222 When given `-Wcounterexamples`/`-Wcex`, bison will now output
223 counterexamples for conflicts.
225 **** Unifying Counterexamples
227 Unifying counterexamples are strings which can be parsed in two ways due
228 to the conflict. For example on a grammar that contains the usual
229 "dangling else" ambiguity:
232 else.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
233 else.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
236 else.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
237 else.y: warning: shift/reduce conflict on token "else" [-Wcounterexamples]
238 Example: "if" exp "then" "if" exp "then" exp • "else" exp
241 ↳ "if" exp "then" exp
242 ↳ "if" exp "then" exp • "else" exp
243 Example: "if" exp "then" "if" exp "then" exp • "else" exp
246 ↳ "if" exp "then" exp "else" exp
247 ↳ "if" exp "then" exp •
249 When text styling is enabled, colors are used in the examples and the
250 derivations to highlight the structure of both analyses. In this case,
252 "if" exp "then" [ "if" exp "then" exp • ] "else" exp
256 "if" exp "then" [ "if" exp "then" exp • "else" exp ]
259 The counterexamples are "focused", in two different ways. First, they do
260 not clutter the output with all the derivations from the start symbol,
261 rather they start on the "conflicted nonterminal". They go straight to the
262 point. Second, they don't "expand" nonterminal symbols uselessly.
264 **** Nonunifying Counterexamples
266 In the case of the dangling else, Bison found an example that can be
267 parsed in two ways (therefore proving that the grammar is ambiguous).
268 When it cannot find such an example, it instead generates two examples
269 that are the same up until the dot:
272 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
273 foo.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
274 foo.y:4.4-7: warning: rule useless in parser due to conflicts [-Wother]
279 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
280 foo.y: warning: shift/reduce conflict on token ID [-Wcounterexamples]
281 First example: expr • ID ',' ID $end
288 Second example: expr • ID $end
294 foo.y:4.4-7: warning: rule useless in parser due to conflicts [-Wother]
298 In these cases, the parser usually doesn't have enough lookahead to
299 differentiate the two given examples.
303 Counterexamples are also included in the report when given
304 `--report=counterexamples`/`-rcex` (or `--report=all`), with more
309 1 exp: "if" exp "then" exp • [$end, "then", "else"]
310 2 | "if" exp "then" exp • "else" exp
312 "else" shift, and go to state 8
314 "else" [reduce using rule 1 (exp)]
315 $default reduce using rule 1 (exp)
317 shift/reduce conflict on token "else":
318 1 exp: "if" exp "then" exp •
319 2 exp: "if" exp "then" exp • "else" exp
320 Example: "if" exp "then" "if" exp "then" exp • "else" exp
323 ↳ "if" exp "then" exp
324 ↳ "if" exp "then" exp • "else" exp
325 Example: "if" exp "then" "if" exp "then" exp • "else" exp
328 ↳ "if" exp "then" exp "else" exp
329 ↳ "if" exp "then" exp •
331 *** File prefix mapping
333 Contributed by Joshua Watt.
335 Bison learned a new argument, `--file-prefix-map OLD=NEW`. Any file path
336 in the output (specifically `#line` directives and `#ifdef` header guards)
337 that begins with the prefix OLD will have it replaced with the prefix NEW,
338 similar to the `-ffile-prefix-map` in GCC. This option can be used to
339 make bison output reproducible.
345 When text styling is enabled and the terminal supports it, the warnings
346 now include hyperlinks to the documentation.
348 *** Relocatable installation
350 When installed to be relocatable (via `configure --enable-relocatable`),
351 bison will now also look for a relocated m4.
355 The `filename_type` %define variable was renamed `api.filename.type`.
358 %define filename_type "symbol"
362 %define api.filename.type {symbol}
364 (Or let `bison --update` do it for you).
366 It now defaults to `const std::string` instead of `std::string`.
368 *** Deprecated %define variable names
370 The following variables have been renamed for consistency. Backward
371 compatibility is ensured, but upgrading is recommended.
373 filename_type -> api.filename.type
374 package -> api.package
376 *** Push parsers no longer clear their state when parsing is finished
378 Previously push-parsers cleared their state when parsing was finished (on
379 success and on failure). This made it impossible to check if there were
380 parse errors, since `yynerrs` was also reset. This can be especially
381 troublesome when used in autocompletion, since a parser with error
382 recovery would suggest (irrelevant) expected tokens even if there were
385 Now the parser state can be examined when parsing is finished. The parser
386 state is reset when starting a new parse.
392 The bistromathic demonstrates %param and how to quote sources in the error
396 1.5-7: syntax error: expected end of file or + or - or * or / or ^ before number
402 *** Include the generated header (yacc.c)
404 Historically, when --defines was used, bison generated a header and pasted
405 an exact copy of it into the generated parser implementation file. Since
406 Bison 3.4 it is possible to specify that the header should be `#include`d,
407 and how. For instance
409 %define api.header.include {"parse.h"}
413 %define api.header.include {<parser/parse.h>}
415 Now api.header.include defaults to `"header-basename"`, as was intended in
416 Bison 3.4, where `header-basename` is the basename of the generated
417 header. This is disabled when the generated header is `y.tab.h`, to
418 comply with Automake's ylwrap.
420 *** String aliases are faithfully propagated
422 Bison used to interpret user strings (i.e., decoding backslash escapes)
423 when reading them, and to escape them (i.e., issue non-printable
424 characters as backslash escapes, taking the locale into account) when
425 outputting them. As a consequence non-ASCII strings (say in UTF-8) ended
426 up "ciphered" as sequences of backslash escapes. This happened not only
427 in the generated sources (where the compiler will reinterpret them), but
428 also in all the generated reports (text, xml, html, dot, etc.). Reports
429 were therefore not readable when string aliases were not pure ASCII.
430 Worse yet: the output depended on the user's locale.
432 Now Bison faithfully treats the string aliases exactly the way the user
433 spelled them. This fixes all the aforementioned problems. However, now,
434 string aliases semantically equivalent but syntactically different (e.g.,
435 "A", "\x41", "\101") are considered to be different.
437 *** Crash when generating IELR
439 An old, well hidden, bug in the generation of IELR parsers was fixed.
442 * Noteworthy changes in release 3.6.4 (2020-06-15) [stable]
446 In glr.cc some internal macros leaked in the user's code, and could damage
447 access to the token kinds.
450 * Noteworthy changes in release 3.6.3 (2020-06-03) [stable]
454 Incorrect comments in the generated parsers.
456 Warnings in push parsers (yacc.c).
458 Incorrect display of gotos in LAC traces (lalr1.cc).
461 * Noteworthy changes in release 3.6.2 (2020-05-17) [stable]
465 Some tests were fixed.
467 When token aliases contain comment delimiters:
469 %token FOO "/* foo */"
471 bison used to emit "nested" comments, which is invalid C.
474 * Noteworthy changes in release 3.6.1 (2020-05-10) [stable]
478 Restored ANSI-C compliance in yacc.c.
480 GNU readline portability issues.
482 In C++, yy::parser::symbol_name is now a public member, as was intended.
486 In C++, yy::parser::symbol_type now has a public name() member function.
489 * Noteworthy changes in release 3.6 (2020-05-08) [stable]
491 ** Backward incompatible changes
493 TL;DR: replace "#define YYERROR_VERBOSE 1" by "%define parse.error verbose".
495 The YYERROR_VERBOSE macro is no longer supported; the parsers that still
496 depend on it will now produce Yacc-like error messages (just "syntax
497 error"). It was superseded by the "%error-verbose" directive in Bison
498 1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that support
499 for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
500 (2013-07-25), "%error-verbose" is deprecated in favor of "%define
501 parse.error verbose".
503 ** Deprecated features
505 The YYPRINT macro, which works only with yacc.c and only for tokens, was
506 obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
507 It is deprecated and its support will be removed eventually.
511 *** Improved syntax error messages
513 Two new values for the %define parse.error variable offer more control to
514 the user. Available in all the skeletons (C, C++, Java).
516 **** %define parse.error detailed
518 The behavior of "%define parse.error detailed" is closely resembling that
519 of "%define parse.error verbose" with a few exceptions. First, it is safe
520 to use non-ASCII characters in token aliases (with 'verbose', the result
521 depends on the locale with which bison was run). Second, a yysymbol_name
522 function is exposed to the user, instead of the yytnamerr function and the
523 yytname table. Third, token internationalization is supported (see
526 **** %define parse.error custom
528 With this directive, the user forges and emits the syntax error message
529 herself by defining the yyreport_syntax_error function. A new type,
530 yypcontext_t, captures the circumstances of the error, and provides the
531 user with functions to get details, such as yypcontext_expected_tokens to
532 get the list of expected token kinds.
534 A possible implementation of yyreport_syntax_error is:
537 yyreport_syntax_error (const yypcontext_t *ctx)
540 YY_LOCATION_PRINT (stderr, *yypcontext_location (ctx));
541 fprintf (stderr, ": syntax error");
542 // Report the tokens expected at this point.
544 enum { TOKENMAX = 10 };
545 yysymbol_kind_t expected[TOKENMAX];
546 int n = yypcontext_expected_tokens (ctx, expected, TOKENMAX);
548 // Forward errors to yyparse.
551 for (int i = 0; i < n; ++i)
552 fprintf (stderr, "%s %s",
553 i == 0 ? ": expected" : " or", yysymbol_name (expected[i]));
555 // Report the unexpected token.
557 yysymbol_kind_t lookahead = yypcontext_token (ctx);
558 if (lookahead != YYSYMBOL_YYEMPTY)
559 fprintf (stderr, " before %s", yysymbol_name (lookahead));
561 fprintf (stderr, "\n");
565 **** Token aliases internationalization
567 When the %define variable parse.error is set to `custom` or `detailed`,
568 one may specify which token aliases are to be translated using _(). For
580 In that case the user must define _() and N_(), and yysymbol_name returns
581 the translated symbol (i.e., it returns '_("variable")' rather that
582 '"variable"'). In Java, the user must provide an i18n() function.
584 *** List of expected tokens (yacc.c)
586 Push parsers may invoke yypstate_expected_tokens at any point during
587 parsing (including even before submitting the first token) to get the list
588 of possible tokens. This feature can be used to propose autocompletion
589 (see below the "bistromathic" example).
591 It makes little sense to use this feature without enabling LAC (lookahead
594 *** Returning the error token
596 When the scanner returns an invalid token or the undefined token
597 (YYUNDEF), the parser generates an error message and enters error
598 recovery. Because of that error message, most scanners that find lexical
599 errors generate an error message, and then ignore the invalid input
600 without entering the error-recovery.
602 The scanners may now return YYerror, the error token, to enter the
603 error-recovery mode without triggering an additional error message. See
604 the bistromathic for an example.
606 *** Deep overhaul of the symbol and token kinds
608 To avoid the confusion with types in programming languages, we now refer
609 to token and symbol "kinds" instead of token and symbol "types". The
610 documentation and error messages have been revised.
612 All the skeletons have been updated to use dedicated enum types rather
613 than integral types. Special symbols are now regular citizens, instead of
614 being declared in ad hoc ways.
618 The "token kind" is what is returned by the scanner, e.g., PLUS, NUMBER,
619 LPAREN, etc. While backward compatibility is of course ensured, users are
620 nonetheless invited to replace their uses of "enum yytokentype" by
623 This type now also includes tokens that were previously hidden: YYEOF (end
624 of input), YYUNDEF (undefined token), and YYerror (error token). They
625 now have string aliases, internationalized when internationalization is
626 enabled. Therefore, by default, error messages now refer to "end of file"
627 (internationalized) rather than the cryptic "$end", or to "invalid token"
628 rather than "$undefined".
630 Therefore in most cases it is now useless to define the end-of-line token
633 %token T_EOF 0 "end of file"
635 Rather simply use "YYEOF" in your scanner.
639 The "symbol kinds" is what the parser actually uses. (Unless the
640 api.token.raw %define variable is used, the symbol kind of a terminal
641 differs from the corresponding token kind.)
643 They are now exposed as a enum, "yysymbol_kind_t".
645 This allows users to tailor the error messages the way they want, or to
646 process some symbols in a specific way in autocompletion (see the
647 bistromathic example below).
649 *** Modernize display of explanatory statements in diagnostics
651 Since Bison 2.7, output was indented four spaces for explanatory
652 statements. For example:
654 input.y:2.7-13: error: %type redeclaration for exp
655 input.y:1.7-11: previous declaration
657 Since the introduction of caret-diagnostics, it became less clear. This
658 indentation has been removed and submessages are displayed similarly as in
661 input.y:2.7-13: error: %type redeclaration for exp
662 2 | %type <float> exp
664 input.y:1.7-11: note: previous declaration
668 Contributed by Victor Morales Cayuela.
672 The token and symbol kinds are yy::parser::token_kind_type and
673 yy::parser::symbol_kind_type.
675 The symbol_type::kind() member function allows to get the kind of a
676 symbol. This can be used to write unit tests for scanners, e.g.,
678 yy::parser::symbol_type t = make_NUMBER ("123");
679 assert (t.kind () == yy::parser::symbol_kind::S_NUMBER);
680 assert (t.value.as<int> () == 123);
686 In order to avoid ambiguities with "type" as in "typing", we now refer to
687 the "token kind" (e.g., `PLUS`, `NUMBER`, etc.) rather than the "token
688 type". We now also refer to the "symbol type" (e.g., `PLUS`, `expr`,
693 There are now examples/java: a very simple calculator, and a more complete
694 one (push-parser, location tracking, and debug traces).
696 The lexcalc example (a simple example in C based on Flex and Bison) now
697 also demonstrates location tracking.
700 A new C example, bistromathic, is a fully featured interactive calculator
701 using many Bison features: pure interface, push parser, autocompletion
702 based on the current parser state (using yypstate_expected_tokens),
703 location tracking, internationalized custom error messages, lookahead
704 correction, rich debug traces, etc.
706 It shows how to depend on the symbol kinds to tailor autocompletion. For
707 instance it recognizes the symbol kind "VARIABLE" to propose
708 autocompletion on the existing variables, rather than of the word
712 * Noteworthy changes in release 3.5.4 (2020-04-05) [stable]
714 ** WARNING: Future backward-incompatibilities!
716 TL;DR: replace "#define YYERROR_VERBOSE 1" by "%define parse.error verbose".
718 Bison 3.6 will no longer support the YYERROR_VERBOSE macro; the parsers
719 that still depend on it will produce Yacc-like error messages (just
720 "syntax error"). It was superseded by the "%error-verbose" directive in
721 Bison 1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that
722 support for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
723 (2013-07-25), "%error-verbose" is deprecated in favor of "%define
724 parse.error verbose".
728 Fix portability issues of the package itself on old compilers.
730 Fix api.token.raw support in Java.
733 * Noteworthy changes in release 3.5.3 (2020-03-08) [stable]
737 Error messages could quote lines containing zero-width characters (such as
738 \005) with incorrect styling. Fixes for similar issues with unexpectedly
739 short lines (e.g., the file was changed between parsing and diagnosing).
741 Some unlikely crashes found by fuzzing have been fixed. This is only
742 about bison itself, not the generated parsers.
745 * Noteworthy changes in release 3.5.2 (2020-02-13) [stable]
749 Portability issues and minor cosmetic issues.
751 The lalr1.cc skeleton properly rejects unsupported values for parse.lac
755 * Noteworthy changes in release 3.5.1 (2020-01-19) [stable]
761 Fix compiler warnings.
764 * Noteworthy changes in release 3.5 (2019-12-11) [stable]
766 ** Backward incompatible changes
768 Lone carriage-return characters (aka \r or ^M) in the grammar files are no
769 longer treated as end-of-lines. This changes the diagnostics, and in
770 particular their locations.
772 In C++, line numbers and columns are now represented as 'int' not
773 'unsigned', so that integer overflow on positions is easily checkable via
774 'gcc -fsanitize=undefined' and the like. This affects the API for
775 positions. The default position and location classes now expose
776 'counter_type' (int), used to define line and column numbers.
778 ** Deprecated features
780 The YYPRINT macro, which works only with yacc.c and only for tokens, was
781 obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
782 It is deprecated and its support will be removed eventually.
786 *** Lookahead correction in C++
788 Contributed by Adrian Vogelsgesang.
790 The C++ deterministic skeleton (lalr1.cc) now supports LAC, via the
791 %define variable parse.lac.
793 *** Variable api.token.raw: Optimized token numbers (all skeletons)
795 In the generated parsers, tokens have two numbers: the "external" token
796 number as returned by yylex (which starts at 257), and the "internal"
797 symbol number (which starts at 3). Each time yylex is called, a table
798 lookup maps the external token number to the internal symbol number.
800 When the %define variable api.token.raw is set, tokens are assigned their
801 internal number, which saves one table lookup per token, and also saves
802 the generation of the mapping table.
804 The gain is typically moderate, but in extreme cases (very simple user
805 actions), a 10% improvement can be observed.
807 *** Generated parsers use better types for states
809 Stacks now use the best integral type for state numbers, instead of always
810 using 15 bits. As a result "small" parsers now have a smaller memory
811 footprint (they use 8 bits), and there is support for large automata (16
812 bits), and extra large (using int, i.e., typically 31 bits).
814 *** Generated parsers prefer signed integer types
816 Bison skeletons now prefer signed to unsigned integer types when either
817 will do, as the signed types are less error-prone and allow for better
818 checking with 'gcc -fsanitize=undefined'. Also, the types chosen are now
819 portable to unusual machines where char, short and int are all the same
820 width. On non-GNU platforms this may entail including <limits.h> and (if
821 available) <stdint.h> to define integer types and constants.
823 *** A skeleton for the D programming language
825 For the last few releases, Bison has shipped a stealth experimental
826 skeleton: lalr1.d. It was first contributed by Oliver Mangold, based on
827 Paolo Bonzini's lalr1.java, and was cleaned and improved thanks to
830 However, because nobody has committed to improving, testing, and
831 documenting this skeleton, it is not clear that it will be supported in
834 The lalr1.d skeleton *is functional*, and works well, as demonstrated in
835 examples/d/calc.d. Please try it, enjoy it, and... commit to support it.
837 *** Debug traces in Java
839 The Java backend no longer emits code and data for parser tracing if the
840 %define variable parse.trace is not defined.
844 *** New diagnostic: -Wdangling-alias
846 String literals, which allow for better error messages, are (too)
847 liberally accepted by Bison, which might result in silent errors. For
850 %type <exVal> cond "condition"
852 does not define "condition" as a string alias to 'cond' (nonterminal
853 symbols do not have string aliases). It is rather equivalent to
856 %token <exVal> "condition"
858 i.e., it gives the type 'exVal' to the "condition" token, which was
859 clearly not the intention.
861 Also, because string aliases need not be defined, typos such as "baz"
862 instead of "bar" will be not reported.
864 The option `-Wdangling-alias` catches these situations. On
867 %type <ival> foo "foo"
871 bison -Wdangling-alias reports
873 warning: string literal not attached to a symbol
874 | %type <ival> foo "foo"
876 warning: string literal not attached to a symbol
880 The `-Wall` option does not (yet?) include `-Wdangling-alias`.
882 *** Better POSIX Yacc compatibility diagnostics
884 POSIX Yacc restricts %type to nonterminals. This is now diagnosed by
888 %type <ival> TOKEN1 TOKEN2 't'
895 input.y:2.15-20: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
896 2 | %type <ival> TOKEN1 TOKEN2 't'
898 input.y:2.29-31: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
899 2 | %type <ival> TOKEN1 TOKEN2 't'
901 input.y:2.22-27: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
902 2 | %type <ival> TOKEN1 TOKEN2 't'
905 *** Diagnostics with insertion
907 The diagnostics now display the suggestion below the underlined source.
908 Replacement for undeclared symbols are now also suggested.
915 foo.y:2.7-9: error: symbol 'lis' is used, but is not defined as a token and has no rules; did you mean 'list'?
919 foo.y:2.16: warning: empty rule without %empty [-Wempty-rule]
923 foo.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
925 *** Diagnostics about long lines
927 Quoted sources may now be truncated to fit the screen. For instance, on a
928 30-column wide terminal:
935 foo.y:1.34-36: warning: symbol FOO redeclared [-Wother]
938 foo.y:1.8-10: previous declaration
941 foo.y:1.62-64: warning: symbol FOO redeclared [-Wother]
944 foo.y:1.8-10: previous declaration
950 *** Debugging glr.c and glr.cc
952 The glr.c skeleton always had asserts to check its own behavior (not the
953 user's). These assertions are now under the control of the parse.assert
954 %define variable (disabled by default).
958 Several new compiler warnings in the generated output have been avoided.
959 Some unused features are no longer emitted. Cleaner generated code in
964 Portability issues in the test suite.
966 In theory, parsers using %nonassoc could crash when reporting verbose
967 error messages. This unlikely bug has been fixed.
969 In Java, %define api.prefix was ignored. It now behaves as expected.
972 * Noteworthy changes in release 3.4.2 (2019-09-12) [stable]
976 In some cases, when warnings are disabled, bison could emit tons of white
977 spaces as diagnostics.
979 When running out of memory, bison could crash (found by fuzzing).
981 When defining twice the EOF token, bison would crash.
983 New warnings from recent compilers have been addressed in the generated
984 parsers (yacc.c, glr.c, glr.cc).
986 When lone carriage-return characters appeared in the input file,
987 diagnostics could hang forever.
990 * Noteworthy changes in release 3.4.1 (2019-05-22) [stable]
997 * Noteworthy changes in release 3.4 (2019-05-19) [stable]
999 ** Deprecated features
1001 The %pure-parser directive is deprecated in favor of '%define api.pure'
1002 since Bison 2.3b (2008-05-27), but no warning was issued; there is one
1003 now. Note that since Bison 2.7 you are strongly encouraged to use
1004 '%define api.pure full' instead of '%define api.pure'.
1008 *** Colored diagnostics
1010 As an experimental feature, diagnostics are now colored, controlled by the
1011 new options --color and --style.
1013 To use them, install the libtextstyle library before configuring Bison.
1014 It is available from
1016 https://alpha.gnu.org/gnu/gettext/
1020 https://alpha.gnu.org/gnu/gettext/libtextstyle-0.8.tar.gz
1022 The option --color supports the following arguments:
1023 - always, yes: Enable colors.
1024 - never, no: Disable colors.
1025 - auto, tty (default): Enable colors if the output device is a tty.
1027 To customize the styles, create a CSS file similar to
1031 .error { font-weight: 800; text-decoration: underline; }
1034 then invoke bison with --style=bison-bw.css, or set the BISON_STYLE
1035 environment variable to "bison-bw.css".
1037 *** Disabling output
1039 When given -fsyntax-only, the diagnostics are reported, but no output is
1042 The name of this option is somewhat misleading as bison does more than
1043 just checking the syntax: every stage is run (including checking for
1044 conflicts for instance), except the generation of the output files.
1046 *** Include the generated header (yacc.c)
1048 Before, when --defines is used, bison generated a header, and pasted an
1049 exact copy of it into the generated parser implementation file. If the
1050 header name is not "y.tab.h", it is now #included instead of being
1053 To use an '#include' even if the header name is "y.tab.h" (which is what
1054 happens with --yacc, or when using the Autotools' ylwrap), define
1055 api.header.include to the exact argument to pass to #include. For
1058 %define api.header.include {"parse.h"}
1062 %define api.header.include {<parser/parse.h>}
1064 *** api.location.type is now supported in C (yacc.c, glr.c)
1066 The %define variable api.location.type defines the name of the type to use
1067 for locations. When defined, Bison no longer defines YYLTYPE.
1069 This can be used in programs with several parsers to factor their
1070 definition of locations: let one of them generate them, and the others
1077 In conformance with the recommendations of the Graphviz team, if %require
1078 "3.4" (or better) is specified, the option --graph generates a *.gv file
1079 by default, instead of *.dot.
1081 *** Diagnostics overhaul
1083 Column numbers were wrong with multibyte characters, which would also
1084 result in skewed diagnostics with carets. Beside, because we were
1085 indenting the quoted source with a single space, lines with tab characters
1086 were incorrectly underlined.
1088 To address these issues, and to be clearer, Bison now issues diagnostics
1089 as GCC9 does. For instance it used to display (there's a tab before the
1092 foo.y:3.37-38: error: $2 of ‘expr’ has no declared type
1093 expr: expr '+' "number" { $$ = $1 + $2; }
1097 foo.y:3.37-38: error: $2 of ‘expr’ has no declared type
1098 3 | expr: expr '+' "number" { $$ = $1 + $2; }
1101 Other constructs now also have better locations, resulting in more precise
1104 *** Fix-it hints for %empty
1106 Running Bison with -Wempty-rules and --update will remove incorrect %empty
1107 annotations, and add the missing ones.
1109 *** Generated reports
1111 The format of the reports (parse.output) was improved for readability.
1113 *** Better support for --no-line.
1115 When --no-line is used, the generated files are now cleaner: no lines are
1116 generated instead of empty lines. Together with using api.header.include,
1117 that should help people saving the generated files into version control
1118 systems get smaller diffs.
1122 A new example in C shows an simple infix calculator with a hand-written
1123 scanner (examples/c/calc).
1125 A new example in C shows a reentrant parser (capable of recursive calls)
1126 built with Flex and Bison (examples/c/reccalc).
1128 There is a new section about the history of Yaccs and Bison.
1132 A few obscure bugs were fixed, including the second oldest (known) bug in
1133 Bison: it was there when Bison was entered in the RCS version control
1134 system, in December 1987. See the NEWS of Bison 3.3 for the previous
1138 * Noteworthy changes in release 3.3.2 (2019-02-03) [stable]
1142 Bison 3.3 failed to generate parsers for grammars with unused nonterminal
1146 * Noteworthy changes in release 3.3.1 (2019-01-27) [stable]
1150 The option -y/--yacc used to imply -Werror=yacc, which turns uses of Bison
1151 extensions into errors. It now makes them simple warnings (-Wyacc).
1154 * Noteworthy changes in release 3.3 (2019-01-26) [stable]
1156 A new mailing list was created, Bison Announce. It is low traffic, and is
1157 only about announcing new releases and important messages (e.g., polls
1158 about major decisions to make).
1160 https://lists.gnu.org/mailman/listinfo/bison-announce
1162 ** Backward incompatible changes
1164 Support for DJGPP, which has been unmaintained and untested for years, is
1167 ** Deprecated features
1169 A new feature, --update (see below) helps adjusting existing grammars to
1172 *** Deprecated directives
1174 The %error-verbose directive is deprecated in favor of '%define
1175 parse.error verbose' since Bison 3.0, but no warning was issued.
1177 The '%name-prefix "xx"' directive is deprecated in favor of '%define
1178 api.prefix {xx}' since Bison 3.0, but no warning was issued. These
1179 directives are slightly different, you might need to adjust your code.
1180 %name-prefix renames only symbols with external linkage, while api.prefix
1181 also renames types and macros, including YYDEBUG, YYTOKENTYPE,
1182 yytokentype, YYSTYPE, YYLTYPE, etc.
1184 Users of Flex that move from '%name-prefix "xx"' to '%define api.prefix
1185 {xx}' will typically have to update YY_DECL from
1187 #define YY_DECL int xxlex (YYSTYPE *yylval, YYLTYPE *yylloc)
1191 #define YY_DECL int xxlex (XXSTYPE *yylval, XXLTYPE *yylloc)
1193 *** Deprecated %define variable names
1195 The following variables, mostly related to parsers in Java, have been
1196 renamed for consistency. Backward compatibility is ensured, but upgrading
1199 abstract -> api.parser.abstract
1200 annotations -> api.parser.annotations
1201 extends -> api.parser.extends
1202 final -> api.parser.final
1203 implements -> api.parser.implements
1204 parser_class_name -> api.parser.class
1205 public -> api.parser.public
1206 strictfp -> api.parser.strictfp
1210 *** Generation of fix-its for IDEs/Editors
1212 When given the new option -ffixit (aka -fdiagnostics-parseable-fixits),
1213 bison now generates machine readable editing instructions to fix some
1214 issues. Currently, this is mostly limited to updating deprecated
1215 directives and removing duplicates. For instance:
1219 %define parser_class_name "Parser"
1220 %define api.parser.class "Parser"
1224 See the "fix-it:" lines below:
1226 $ bison -ffixit foo.y
1227 foo.y:1.1-14: warning: deprecated directive, use '%define parse.error verbose' [-Wdeprecated]
1230 fix-it:"foo.y":{1:1-1:15}:"%define parse.error verbose"
1231 foo.y:2.1-34: warning: deprecated directive, use '%define api.parser.class {Parser}' [-Wdeprecated]
1232 %define parser_class_name "Parser"
1233 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1234 fix-it:"foo.y":{2:1-2:35}:"%define api.parser.class {Parser}"
1235 foo.y:3.1-33: error: %define variable 'api.parser.class' redefined
1236 %define api.parser.class "Parser"
1237 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1238 foo.y:2.1-34: previous definition
1239 %define parser_class_name "Parser"
1240 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1241 fix-it:"foo.y":{3:1-3:34}:""
1242 foo.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
1244 This uses the same output format as GCC and Clang.
1246 *** Updating grammar files
1248 Fixes can be applied on the fly. The previous example ends with the
1249 suggestion to re-run bison with the option -u/--update, which results in a
1250 cleaner grammar file.
1252 $ bison --update foo.y
1254 bison: file 'foo.y' was updated (backup: 'foo.y~')
1257 %define parse.error verbose
1258 %define api.parser.class {Parser}
1262 *** Bison is now relocatable
1264 If you pass '--enable-relocatable' to 'configure', Bison is relocatable.
1266 A relocatable program can be moved or copied to a different location on
1267 the file system. It can also be used through mount points for network
1268 sharing. It is possible to make symbolic links to the installed and moved
1269 programs, and invoke them through the symbolic link.
1271 *** %expect and %expect-rr modifiers on individual rules
1273 One can now document (and check) which rules participate in shift/reduce
1274 and reduce/reduce conflicts. This is particularly important GLR parsers,
1275 where conflicts are a normal occurrence. For example,
1291 | argument_list ',' expression
1296 Looking at the output from -v, one can see that the shift/reduce conflict
1297 here is due to the fact that the parser does not know whether to reduce
1298 arguments to argument_list until it sees the token _after_ the following
1299 ','. By marking the rule with %expect 1 (because there is a conflict in
1300 one state), we document the source of the 1 overall shift/reduce conflict.
1302 In GLR parsers, we can use %expect-rr in a rule for reduce/reduce
1303 conflicts. In this case, we mark each of the conflicting rules. For
1312 target_list '=' expr ';'
1318 | target ',' target_list
1327 | expr ',' expr_list
1335 In a statement such as
1339 the parser must reduce x to a target or an expr, but does not know which
1340 until it sees the '='. So we notate the two possible reductions to
1341 indicate that each conflicts in one rule.
1343 This feature needs user feedback, and might evolve in the future.
1345 *** C++: Actual token constructors
1347 When variants and token constructors are enabled, in addition to the
1348 type-safe named token constructors (make_ID, make_INT, etc.), we now
1349 generate genuine constructors for symbol_type.
1351 For instance with these declarations
1357 you may use these constructors:
1359 symbol_type (int token, const std::string&);
1360 symbol_type (int token, const int&);
1361 symbol_type (int token);
1363 Correct matching between token types and value types is checked via
1364 'assert'; for instance, 'symbol_type (ID, 42)' would abort. Named
1365 constructors are preferable, as they offer better type safety (for
1366 instance 'make_ID (42)' would not even compile), but symbol_type
1367 constructors may help when token types are discovered at run-time, e.g.,
1370 if (auto i = lookup_keyword (yytext))
1371 return yy::parser::symbol_type (i);
1373 return yy::parser::make_ID (yytext);
1376 *** C++: Variadic emplace
1378 If your application requires C++11 and you don't use symbol constructors,
1379 you may now use a variadic emplace for semantic values:
1381 %define api.value.type variant
1382 %token <std::pair<int, int>> PAIR
1386 int yylex (parser::semantic_type *lvalp)
1388 lvalp->emplace <std::pair<int, int>> (1, 2);
1389 return parser::token::PAIR;
1392 *** C++: Syntax error exceptions in GLR
1394 The glr.cc skeleton now supports syntax_error exceptions thrown from user
1395 actions, or from the scanner.
1397 *** More POSIX Yacc compatibility warnings
1399 More Bison specific directives are now reported with -y or -Wyacc. This
1400 change was ready since the release of Bison 3.0 in September 2015. It was
1401 delayed because Autoconf used to define YACC as `bison -y`, which resulted
1402 in numerous warnings for Bison users that use the GNU Build System.
1404 If you still experience that problem, either redefine YACC as `bison -o
1405 y.tab.c`, or pass -Wno-yacc to Bison.
1407 *** The tables yyrhs and yyphrs are back
1409 Because no Bison skeleton uses them, these tables were removed (no longer
1410 passed to the skeletons, not even computed) in 2008. However, some users
1411 have expressed interest in being able to use them in their own skeletons.
1415 *** Incorrect number of reduce/reduce conflicts
1417 On a grammar such as
1419 exp: "num" | "num" | "num"
1421 bison used to report a single RR conflict, instead of two. This is now
1422 fixed. This was the oldest (known) bug in Bison: it was there when Bison
1423 was entered in the RCS version control system, in December 1987.
1425 Some grammar files might have to adjust their %expect-rr.
1427 *** Parser directives that were not careful enough
1429 Passing invalid arguments to %nterm, for instance character literals, used
1430 to result in unclear error messages.
1434 The examples/ directory (installed in .../share/doc/bison/examples) has
1435 been restructured per language for clarity. The examples come with a
1436 README and a Makefile. Not only can they be used to toy with Bison, they
1437 can also be starting points for your own grammars.
1439 There is now a Java example, and a simple example in C based on Flex and
1440 Bison (examples/c/lexcalc/).
1446 They now use noexcept and constexpr. Please, report missing annotations.
1448 *** Symbol Declarations
1450 The syntax of the variation directives to declare symbols was overhauled
1451 for more consistency, and also better POSIX Yacc compliance (which, for
1452 instance, allows "%type" without actually providing a type). The %nterm
1453 directive, supported by Bison since its inception, is now documented and
1454 officially supported.
1456 The syntax is now as follows:
1458 %token TAG? ( ID NUMBER? STRING? )+ ( TAG ( ID NUMBER? STRING? )+ )*
1459 %left TAG? ( ID NUMBER? )+ ( TAG ( ID NUMBER? )+ )*
1460 %type TAG? ( ID | CHAR | STRING )+ ( TAG ( ID | CHAR | STRING )+ )*
1461 %nterm TAG? ID+ ( TAG ID+ )*
1463 where TAG denotes a type tag such as ‘<ival>’, ID denotes an identifier
1464 such as ‘NUM’, NUMBER a decimal or hexadecimal integer such as ‘300’ or
1465 ‘0x12d’, CHAR a character literal such as ‘'+'’, and STRING a string
1466 literal such as ‘"number"’. The post-fix quantifiers are ‘?’ (zero or
1467 one), ‘*’ (zero or more) and ‘+’ (one or more).
1470 * Noteworthy changes in release 3.2.4 (2018-12-24) [stable]
1474 Fix the move constructor of symbol_type.
1476 Always provide a copy constructor for symbol_type, even in modern C++.
1479 * Noteworthy changes in release 3.2.3 (2018-12-18) [stable]
1483 Properly support token constructors in C++ with types that include commas
1484 (e.g., std::pair<int, int>). A regression introduced in Bison 3.2.
1487 * Noteworthy changes in release 3.2.2 (2018-11-21) [stable]
1491 C++ portability issues.
1494 * Noteworthy changes in release 3.2.1 (2018-11-09) [stable]
1498 Several portability issues have been fixed in the build system, in the
1499 test suite, and in the generated parsers in C++.
1502 * Noteworthy changes in release 3.2 (2018-10-29) [stable]
1504 ** Backward incompatible changes
1506 Support for DJGPP, which has been unmaintained and untested for years, is
1507 obsolete. Unless there is activity to revive it, it will be removed.
1511 %printers should use yyo rather than yyoutput to denote the output stream.
1513 Variant-based symbols in C++ should use emplace() rather than build().
1515 In C++ parsers, parser::operator() is now a synonym for the parser::parse.
1519 A new section, "A Simple C++ Example", is a tutorial for parsers in C++.
1521 A comment in the generated code now emphasizes that users should not
1522 depend upon non-documented implementation details, such as macros starting
1527 *** C++: Support for move semantics (lalr1.cc)
1529 The lalr1.cc skeleton now fully supports C++ move semantics, while
1530 maintaining compatibility with C++98. You may now store move-only types
1531 when using Bison's variants. For instance:
1538 %skeleton "lalr1.cc"
1539 %define api.value.type variant
1543 %token <int> INT "int";
1544 %type <std::unique_ptr<int>> int;
1545 %type <std::vector<std::unique_ptr<int>>> list;
1549 | list int { $$ = std::move($1); $$.emplace_back(std::move($2)); }
1551 int: "int" { $$ = std::make_unique<int>($1); }
1553 *** C++: Implicit move of right-hand side values (lalr1.cc)
1555 In modern C++ (C++11 and later), you should always use 'std::move' with
1556 the values of the right-hand side symbols ($1, $2, etc.), as they will be
1557 popped from the stack anyway. Using 'std::move' is mandatory for
1558 move-only types such as unique_ptr, and it provides a significant speedup
1559 for large types such as std::string, or std::vector, etc.
1561 If '%define api.value.automove' is set, every occurrence '$n' is replaced
1562 by 'std::move ($n)'. The second rule in the previous grammar can be
1565 list: list int { $$ = $1; $$.emplace_back($2); }
1567 With automove enabled, the semantic values are no longer lvalues, so do
1568 not use the swap idiom:
1570 list: list int { std::swap($$, $1); $$.emplace_back($2); }
1572 This idiom is anyway obsolete: it is preferable to move than to swap.
1574 A warning is issued when automove is enabled, and a value is used several
1577 input.yy:16.31-32: warning: multiple occurrences of $2 with api.value.automove enabled [-Wother]
1578 exp: "twice" exp { $$ = $2 + $2; }
1581 Enabling api.value.automove does not require support for modern C++. The
1582 generated code is valid C++98/03, but will use copies instead of moves.
1584 The new examples/c++/variant-11.yy shows these features in action.
1586 *** C++: The implicit default semantic action is always run
1588 When variants are enabled, the default action was not run, so
1596 It now behaves like in all the other cases, as
1598 exp: "number" { $$ = $1; }
1600 possibly using std::move if automove is enabled.
1602 We do not expect backward compatibility issues. However, beware of
1603 forward compatibility issues: if you rely on default actions with
1604 variants, be sure to '%require "3.2"' to avoid older versions of Bison to
1605 generate incorrect parsers.
1607 *** C++: Renaming location.hh
1609 When both %defines and %locations are enabled, Bison generates a
1610 location.hh file. If you don't use locations outside of the parser, you
1611 may avoid its creation with:
1613 %define api.location.file none
1615 However this file is useful if, for instance, your parser builds an AST
1616 decorated with locations: you may use Bison's location independently of
1617 Bison's parser. You can now give it another name, for instance:
1619 %define api.location.file "my-location.hh"
1621 This name can have directory components, and even be absolute. The name
1622 under which the location file is included is controlled by
1623 api.location.include.
1625 This way it is possible to have several parsers share the same location
1628 For instance, in src/foo/parser.hh, generate the include/ast/loc.hh file:
1631 %define api.namespace {foo}
1632 %define api.location.file "include/ast/loc.hh"
1633 %define api.location.include {<ast/loc.hh>}
1635 and use it in src/bar/parser.hh:
1638 %define api.namespace {bar}
1639 %code requires {#include <ast/loc.hh>}
1640 %define api.location.type {bar::location}
1642 Absolute file names are supported, so in your Makefile, passing the flag
1643 -Dapi.location.file='"$(top_srcdir)/include/ast/location.hh"' to bison is
1646 *** C++: stack.hh and position.hh are deprecated
1648 When asked to generate a header file (%defines), the lalr1.cc skeleton
1649 generates a stack.hh file. This file had no interest for users; it is now
1650 made useless: its content is included in the parser definition. It is
1651 still generated for backward compatibility.
1653 When in addition to %defines, location support is requested (%locations),
1654 the file position.hh is also generated. It is now also useless: its
1655 content is now included in location.hh.
1657 These files are no longer generated when your grammar file requires at
1658 least Bison 3.2 (%require "3.2").
1662 Portability issues on MinGW and VS2015.
1664 Portability issues in the test suite.
1666 Portability/warning issues with Flex.
1669 * Noteworthy changes in release 3.1 (2018-08-27) [stable]
1671 ** Backward incompatible changes
1673 Compiling Bison now requires a C99 compiler---as announced during the
1674 release of Bison 3.0, five years ago. Generated parsers do not require a
1677 Support for DJGPP, which has been unmaintained and untested for years, is
1678 obsolete. Unless there is activity to revive it, the next release of Bison
1679 will have it removed.
1683 *** Typed midrule actions
1685 Because their type is unknown to Bison, the values of midrule actions are
1686 not treated like the others: they don't have %printer and %destructor
1687 support. It also prevents C++ (Bison) variants to handle them properly.
1689 Typed midrule actions address these issues. Instead of:
1691 exp: { $<ival>$ = 1; } { $<ival>$ = 2; } { $$ = $<ival>1 + $<ival>2; }
1695 exp: <ival>{ $$ = 1; } <ival>{ $$ = 2; } { $$ = $1 + $2; }
1697 *** Reports include the type of the symbols
1699 The sections about terminal and nonterminal symbols of the '*.output' file
1700 now specify their declared type. For instance, for:
1704 the report now shows '<ival>':
1706 Terminals, with rules where they appear
1710 *** Diagnostics about useless rules
1712 In the following grammar, the 'exp' nonterminal is trivially useless. So,
1713 of course, its rules are useless too.
1717 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1719 Previously all the useless rules were reported, including those whose
1720 left-hand side is the 'exp' nonterminal:
1722 warning: 1 nonterminal useless in grammar [-Wother]
1723 warning: 4 rules useless in grammar [-Wother]
1724 2.14-16: warning: nonterminal useless in grammar: exp [-Wother]
1727 2.14-16: warning: rule useless in grammar [-Wother]
1730 3.6-16: warning: rule useless in grammar [-Wother]
1731 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1733 3.20-30: warning: rule useless in grammar [-Wother]
1734 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1736 3.34-44: warning: rule useless in grammar [-Wother]
1737 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1740 Now, rules whose left-hand side symbol is useless are no longer reported
1741 as useless. The locations of the errors have also been adjusted to point
1742 to the first use of the nonterminal as a left-hand side of a rule:
1744 warning: 1 nonterminal useless in grammar [-Wother]
1745 warning: 4 rules useless in grammar [-Wother]
1746 3.1-3: warning: nonterminal useless in grammar: exp [-Wother]
1747 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1749 2.14-16: warning: rule useless in grammar [-Wother]
1753 *** C++: Generated parsers can be compiled with -fno-exceptions (lalr1.cc)
1755 When compiled with exceptions disabled, the generated parsers no longer
1756 uses try/catch clauses.
1758 Currently only GCC and Clang are supported.
1762 *** A demonstration of variants
1764 A new example was added (installed in .../share/doc/bison/examples),
1765 'variant.yy', which shows how to use (Bison) variants in C++.
1767 The other examples were made nicer to read.
1769 *** Some features are no longer 'experimental'
1771 The following features, mature enough, are no longer flagged as
1772 experimental in the documentation: push parsers, default %printer and
1773 %destructor (typed: <*> and untyped: <>), %define api.value.type union and
1774 variant, Java parsers, XML output, LR family (lr, ielr, lalr), and
1775 semantic predicates (%?).
1779 *** GLR: Predicates support broken by #line directives
1781 Predicates (%?) in GLR such as
1784 %? {new_syntax} 'w' id new_args
1785 | %?{!new_syntax} 'w' id old_args
1787 were issued with #lines in the middle of C code.
1789 *** Printer and destructor with broken #line directives
1791 The #line directives were not properly escaped when emitting the code for
1792 %printer/%destructor, which resulted in compiler errors if there are
1793 backslashes or double-quotes in the grammar file name.
1795 *** Portability on ICC
1797 The Intel compiler claims compatibility with GCC, yet rejects its _Pragma.
1798 Generated parsers now work around this.
1802 There were several small fixes in the test suite and in the build system,
1803 many warnings in bison and in the generated parsers were eliminated. The
1804 documentation also received its share of minor improvements.
1806 Useless code was removed from C++ parsers, and some of the generated
1807 constructors are more 'natural'.
1810 * Noteworthy changes in release 3.0.5 (2018-05-27) [stable]
1814 *** C++: Fix support of 'syntax_error'
1816 One incorrect 'inline' resulted in linking errors about the constructor of
1817 the syntax_error exception.
1819 *** C++: Fix warnings
1821 GCC 7.3 (with -O1 or -O2 but not -O0 or -O3) issued null-dereference
1822 warnings about yyformat being possibly null. It also warned about the
1823 deprecated implicit definition of copy constructors when there's a
1824 user-defined (copy) assignment operator.
1826 *** Location of errors
1828 In C++ parsers, out-of-bounds errors can happen when a rule with an empty
1829 ride-hand side raises a syntax error. The behavior of the default parser
1830 (yacc.c) in such a condition was undefined.
1832 Now all the parsers match the behavior of glr.c: @$ is used as the
1833 location of the error. This handles gracefully rules with and without
1836 *** Portability fixes in the test suite
1838 On some platforms, some Java and/or C++ tests were failing.
1841 * Noteworthy changes in release 3.0.4 (2015-01-23) [stable]
1845 *** C++ with Variants (lalr1.cc)
1847 Fix a compiler warning when no %destructor use $$.
1851 Several portability issues in tests were fixed.
1854 * Noteworthy changes in release 3.0.3 (2015-01-15) [stable]
1858 *** C++ with Variants (lalr1.cc)
1860 Problems with %destructor and '%define parse.assert' have been fixed.
1862 *** Named %union support (yacc.c, glr.c)
1864 Bison 3.0 introduced a regression on named %union such as
1866 %union foo { int ival; };
1868 The possibility to use a name was introduced "for Yacc compatibility".
1869 It is however not required by POSIX Yacc, and its usefulness is not clear.
1871 *** %define api.value.type union with %defines (yacc.c, glr.c)
1873 The C parsers were broken when %defines was used together with "%define
1874 api.value.type union".
1876 *** Redeclarations are reported in proper order
1884 bison used to report:
1886 foo.yy:2.10-11: error: %printer redeclaration for FOO
1889 foo.yy:3.10-11: previous declaration
1893 Now, the "previous" declaration is always the first one.
1898 Bison now installs various files in its docdir (which defaults to
1899 '/usr/local/share/doc/bison'), including the three fully blown examples
1900 extracted from the documentation:
1903 Reverse Polish Calculator, a simple introductory example.
1905 Multi-function Calc, a calculator with memory and functions and located
1908 a calculator in C++ using variant support and token constructors.
1911 * Noteworthy changes in release 3.0.2 (2013-12-05) [stable]
1915 *** Generated source files when errors are reported
1917 When warnings are issued and -Werror is set, bison would still generate
1918 the source files (*.c, *.h...). As a consequence, some runs of "make"
1919 could fail the first time, but not the second (as the files were generated
1922 This is fixed: bison no longer generates this source files, but, of
1923 course, still produces the various reports (*.output, *.xml, etc.).
1925 *** %empty is used in reports
1927 Empty right-hand sides are denoted by '%empty' in all the reports (text,
1928 dot, XML and formats derived from it).
1930 *** YYERROR and variants
1932 When C++ variant support is enabled, an error triggered via YYERROR, but
1933 not caught via error recovery, resulted in a double deletion.
1936 * Noteworthy changes in release 3.0.1 (2013-11-12) [stable]
1940 *** Errors in caret diagnostics
1942 On some platforms, some errors could result in endless diagnostics.
1944 *** Fixes of the -Werror option
1946 Options such as "-Werror -Wno-error=foo" were still turning "foo"
1947 diagnostics into errors instead of warnings. This is fixed.
1949 Actually, for consistency with GCC, "-Wno-error=foo -Werror" now also
1950 leaves "foo" diagnostics as warnings. Similarly, with "-Werror=foo
1951 -Wno-error", "foo" diagnostics are now errors.
1955 As demonstrated in the documentation, one can now leave spaces between
1960 The yacc.1 man page is no longer installed if --disable-yacc was
1963 *** Fixes in the test suite
1965 Bugs and portability issues.
1968 * Noteworthy changes in release 3.0 (2013-07-25) [stable]
1970 ** WARNING: Future backward-incompatibilities!
1972 Like other GNU packages, Bison will start using some of the C99 features
1973 for its own code, especially the definition of variables after statements.
1974 The generated C parsers still aim at C90.
1976 ** Backward incompatible changes
1978 *** Obsolete features
1980 Support for YYFAIL is removed (deprecated in Bison 2.4.2): use YYERROR.
1982 Support for yystype and yyltype is removed (deprecated in Bison 1.875):
1983 use YYSTYPE and YYLTYPE.
1985 Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
1986 1.875): use %lex-param, %parse-param, or %param.
1988 Missing semicolons at the end of actions are no longer added (as announced
1989 in the release 2.5).
1991 *** Use of YACC='bison -y'
1993 TL;DR: With Autoconf <= 2.69, pass -Wno-yacc to (AM_)YFLAGS if you use
1996 Traditional Yacc generates 'y.tab.c' whatever the name of the input file.
1997 Therefore Makefiles written for Yacc expect 'y.tab.c' (and possibly
1998 'y.tab.h' and 'y.output') to be generated from 'foo.y'.
2000 To this end, for ages, AC_PROG_YACC, Autoconf's macro to look for an
2001 implementation of Yacc, was using Bison as 'bison -y'. While it does
2002 ensure compatible output file names, it also enables warnings for
2003 incompatibilities with POSIX Yacc. In other words, 'bison -y' triggers
2004 warnings for Bison extensions.
2006 Autoconf 2.70+ fixes this incompatibility by using YACC='bison -o y.tab.c'
2007 (which also generates 'y.tab.h' and 'y.output' when needed).
2008 Alternatively, disable Yacc warnings by passing '-Wno-yacc' to your Yacc
2009 flags (YFLAGS, or AM_YFLAGS with Automake).
2013 *** The epilogue is no longer affected by internal #defines (glr.c)
2015 The glr.c skeleton uses defines such as #define yylval (yystackp->yyval) in
2016 generated code. These weren't properly undefined before the inclusion of
2017 the user epilogue, so functions such as the following were butchered by the
2018 preprocessor expansion:
2020 int yylex (YYSTYPE *yylval);
2022 This is fixed: yylval, yynerrs, yychar, and yylloc are now valid
2023 identifiers for user-provided variables.
2025 *** stdio.h is no longer needed when locations are enabled (yacc.c)
2027 Changes in Bison 2.7 introduced a dependency on FILE and fprintf when
2028 locations are enabled. This is fixed.
2030 *** Warnings about useless %pure-parser/%define api.pure are restored
2032 ** Diagnostics reported by Bison
2034 Most of these features were contributed by Théophile Ranquet and Victor
2039 Version 2.7 introduced caret errors, for a prettier output. These are now
2040 activated by default. The old format can still be used by invoking Bison
2041 with -fno-caret (or -fnone).
2043 Some error messages that reproduced excerpts of the grammar are now using
2044 the caret information only. For instance on:
2051 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
2052 in.y:2.12-14: warning: rule useless in parser due to conflicts: exp: 'a' [-Wother]
2056 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
2057 in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
2061 and "bison -fno-caret" reports:
2063 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
2064 in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
2066 *** Enhancements of the -Werror option
2068 The -Werror=CATEGORY option is now recognized, and will treat specified
2069 warnings as errors. The warnings need not have been explicitly activated
2070 using the -W option, this is similar to what GCC 4.7 does.
2072 For example, given the following command line, Bison will treat both
2073 warnings related to POSIX Yacc incompatibilities and S/R conflicts as
2074 errors (and only those):
2076 $ bison -Werror=yacc,error=conflicts-sr input.y
2078 If no categories are specified, -Werror will make all active warnings into
2079 errors. For example, the following line does the same the previous example:
2081 $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y
2083 (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)
2085 Note that the categories in this -Werror option may not be prefixed with
2086 "no-". However, -Wno-error[=CATEGORY] is valid.
2088 Note that -y enables -Werror=yacc. Therefore it is now possible to require
2089 Yacc-like behavior (e.g., always generate y.tab.c), but to report
2090 incompatibilities as warnings: "-y -Wno-error=yacc".
2092 *** The display of warnings is now richer
2094 The option that controls a given warning is now displayed:
2096 foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
2098 In the case of warnings treated as errors, the prefix is changed from
2099 "warning: " to "error: ", and the suffix is displayed, in a manner similar
2100 to GCC, as [-Werror=CATEGORY].
2102 For instance, where the previous version of Bison would report (and exit
2105 bison: warnings being treated as errors
2106 input.y:1.1: warning: stray ',' treated as white space
2110 input.y:1.1: error: stray ',' treated as white space [-Werror=other]
2112 *** Deprecated constructs
2114 The new 'deprecated' warning category flags obsolete constructs whose
2115 support will be discontinued. It is enabled by default. These warnings
2116 used to be reported as 'other' warnings.
2118 *** Useless semantic types
2120 Bison now warns about useless (uninhabited) semantic types. Since
2121 semantic types are not declared to Bison (they are defined in the opaque
2122 %union structure), it is %printer/%destructor directives about useless
2123 types that trigger the warning:
2127 %printer {} <type1> <type3>
2128 %destructor {} <type2> <type4>
2130 nterm: term { $$ = $1; };
2132 3.28-34: warning: type <type3> is used, but is not associated to any symbol
2133 4.28-34: warning: type <type4> is used, but is not associated to any symbol
2135 *** Undefined but unused symbols
2137 Bison used to raise an error for undefined symbols that are not used in
2138 the grammar. This is now only a warning.
2141 %destructor {} symbol2
2142 %type <type> symbol3
2146 *** Useless destructors or printers
2148 Bison now warns about useless destructors or printers. In the following
2149 example, the printer for <type1>, and the destructor for <type2> are
2150 useless: all symbols of <type1> (token1) already have a printer, and all
2151 symbols of type <type2> (token2) already have a destructor.
2153 %token <type1> token1
2157 %printer {} token1 <type1> <type3>
2158 %destructor {} token2 <type2> <type4>
2162 The warnings and error messages about shift/reduce and reduce/reduce
2163 conflicts have been normalized. For instance on the following foo.y file:
2167 exp: exp '+' exp | '0' | '0';
2169 compare the previous version of bison:
2172 foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
2173 $ bison -Werror foo.y
2174 bison: warnings being treated as errors
2175 foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
2177 with the new behavior:
2180 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
2181 foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
2182 $ bison -Werror foo.y
2183 foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
2184 foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]
2186 When %expect or %expect-rr is used, such as with bar.y:
2191 exp: exp '+' exp | '0' | '0';
2196 bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
2197 bar.y: expected 0 shift/reduce conflicts
2198 bar.y: expected 0 reduce/reduce conflicts
2203 bar.y: error: shift/reduce conflicts: 1 found, 0 expected
2204 bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
2206 ** Incompatibilities with POSIX Yacc
2208 The 'yacc' category is no longer part of '-Wall', enable it explicitly
2211 ** Additional yylex/yyparse arguments
2213 The new directive %param declares additional arguments to both yylex and
2214 yyparse. The %lex-param, %parse-param, and %param directives support one
2215 or more arguments. Instead of
2217 %lex-param {arg1_type *arg1}
2218 %lex-param {arg2_type *arg2}
2219 %parse-param {arg1_type *arg1}
2220 %parse-param {arg2_type *arg2}
2224 %param {arg1_type *arg1} {arg2_type *arg2}
2226 ** Types of values for %define variables
2228 Bison used to make no difference between '%define foo bar' and '%define
2229 foo "bar"'. The former is now called a 'keyword value', and the latter a
2230 'string value'. A third kind was added: 'code values', such as '%define
2233 Keyword variables are used for fixed value sets, e.g.,
2235 %define lr.type lalr
2237 Code variables are used for value in the target language, e.g.,
2239 %define api.value.type {struct semantic_type}
2241 String variables are used remaining cases, e.g. file names.
2243 ** Variable api.token.prefix
2245 The variable api.token.prefix changes the way tokens are identified in
2246 the generated files. This is especially useful to avoid collisions
2247 with identifiers in the target language. For instance
2249 %token FILE for ERROR
2250 %define api.token.prefix {TOK_}
2252 start: FILE for ERROR;
2254 will generate the definition of the symbols TOK_FILE, TOK_for, and
2255 TOK_ERROR in the generated sources. In particular, the scanner must
2256 use these prefixed token names, although the grammar itself still
2257 uses the short names (as in the sample rule given above).
2259 ** Variable api.value.type
2261 This new %define variable supersedes the #define macro YYSTYPE. The use
2262 of YYSTYPE is discouraged. In particular, #defining YYSTYPE *and* either
2263 using %union or %defining api.value.type results in undefined behavior.
2265 Either define api.value.type, or use "%union":
2272 %token <ival> INT "integer"
2273 %token <sval> STRING "string"
2274 %printer { fprintf (yyo, "%d", $$); } <ival>
2275 %destructor { free ($$); } <sval>
2278 yylval.ival = 42; return INT;
2279 yylval.sval = "42"; return STRING;
2281 The %define variable api.value.type supports both keyword and code values.
2283 The keyword value 'union' means that the user provides genuine types, not
2284 union member names such as "ival" and "sval" above (WARNING: will fail if
2285 -y/--yacc/%yacc is enabled).
2287 %define api.value.type union
2288 %token <int> INT "integer"
2289 %token <char *> STRING "string"
2290 %printer { fprintf (yyo, "%d", $$); } <int>
2291 %destructor { free ($$); } <char *>
2294 yylval.INT = 42; return INT;
2295 yylval.STRING = "42"; return STRING;
2297 The keyword value variant is somewhat equivalent, but for C++ special
2298 provision is made to allow classes to be used (more about this below).
2300 %define api.value.type variant
2301 %token <int> INT "integer"
2302 %token <std::string> STRING "string"
2304 Code values (in braces) denote user defined types. This is where YYSTYPE
2322 %define api.value.type {struct my_value}
2323 %token <u.ival> INT "integer"
2324 %token <u.sval> STRING "string"
2325 %printer { fprintf (yyo, "%d", $$); } <u.ival>
2326 %destructor { free ($$); } <u.sval>
2329 yylval.u.ival = 42; return INT;
2330 yylval.u.sval = "42"; return STRING;
2332 ** Variable parse.error
2334 This variable controls the verbosity of error messages. The use of the
2335 %error-verbose directive is deprecated in favor of "%define parse.error
2338 ** Deprecated %define variable names
2340 The following variables have been renamed for consistency. Backward
2341 compatibility is ensured, but upgrading is recommended.
2343 lr.default-reductions -> lr.default-reduction
2344 lr.keep-unreachable-states -> lr.keep-unreachable-state
2345 namespace -> api.namespace
2346 stype -> api.value.type
2348 ** Semantic predicates
2350 Contributed by Paul Hilfinger.
2352 The new, experimental, semantic-predicate feature allows actions of the
2353 form "%?{ BOOLEAN-EXPRESSION }", which cause syntax errors (as for
2354 YYERROR) if the expression evaluates to 0, and are evaluated immediately
2355 in GLR parsers, rather than being deferred. The result is that they allow
2356 the programmer to prune possible parses based on the values of run-time
2359 ** The directive %expect-rr is now an error in non GLR mode
2361 It used to be an error only if used in non GLR mode, _and_ if there are
2362 reduce/reduce conflicts.
2364 ** Tokens are numbered in their order of appearance
2366 Contributed by Valentin Tolmer.
2368 With '%token A B', A had a number less than the one of B. However,
2369 precedence declarations used to generate a reversed order. This is now
2370 fixed, and introducing tokens with any of %token, %left, %right,
2371 %precedence, or %nonassoc yields the same result.
2373 When mixing declarations of tokens with a literal character (e.g., 'a') or
2374 with an identifier (e.g., B) in a precedence declaration, Bison numbered
2375 the literal characters first. For example
2379 would lead to the tokens declared in this order: 'c' 'd' A B. Again, the
2380 input order is now preserved.
2382 These changes were made so that one can remove useless precedence and
2383 associativity declarations (i.e., map %nonassoc, %left or %right to
2384 %precedence, or to %token) and get exactly the same output.
2386 ** Useless precedence and associativity
2388 Contributed by Valentin Tolmer.
2390 When developing and maintaining a grammar, useless associativity and
2391 precedence directives are common. They can be a nuisance: new ambiguities
2392 arising are sometimes masked because their conflicts are resolved due to
2393 the extra precedence or associativity information. Furthermore, it can
2394 hinder the comprehension of a new grammar: one will wonder about the role
2395 of a precedence, where in fact it is useless. The following changes aim
2396 at detecting and reporting these extra directives.
2398 *** Precedence warning category
2400 A new category of warning, -Wprecedence, was introduced. It flags the
2401 useless precedence and associativity directives.
2403 *** Useless associativity
2405 Bison now warns about symbols with a declared associativity that is never
2406 used to resolve conflicts. In that case, using %precedence is sufficient;
2407 the parsing tables will remain unchanged. Solving these warnings may raise
2408 useless precedence warnings, as the symbols no longer have associativity.
2422 warning: useless associativity for '+', use %precedence [-Wprecedence]
2426 *** Useless precedence
2428 Bison now warns about symbols with a declared precedence and no declared
2429 associativity (i.e., declared with %precedence), and whose precedence is
2430 never used. In that case, the symbol can be safely declared with %token
2431 instead, without modifying the parsing tables. For example:
2435 exp: "var" '=' "number";
2439 warning: useless precedence for '=' [-Wprecedence]
2443 *** Useless precedence and associativity
2445 In case of both useless precedence and associativity, the issue is flagged
2450 exp: "var" '=' "number";
2454 warning: useless precedence and associativity for '=' [-Wprecedence]
2460 With help from Joel E. Denny and Gabriel Rassoul.
2462 Empty rules (i.e., with an empty right-hand side) can now be explicitly
2463 marked by the new %empty directive. Using %empty on a non-empty rule is
2464 an error. The new -Wempty-rule warning reports empty rules without
2465 %empty. On the following grammar:
2475 3.4-5: warning: empty rule without %empty [-Wempty-rule]
2478 5.8-13: error: %empty on non-empty rule
2482 ** Java skeleton improvements
2484 The constants for token names were moved to the Lexer interface. Also, it
2485 is possible to add code to the parser's constructors using "%code init"
2486 and "%define init_throws".
2487 Contributed by Paolo Bonzini.
2489 The Java skeleton now supports push parsing.
2490 Contributed by Dennis Heimbigner.
2492 ** C++ skeletons improvements
2494 *** The parser header is no longer mandatory (lalr1.cc, glr.cc)
2496 Using %defines is now optional. Without it, the needed support classes
2497 are defined in the generated parser, instead of additional files (such as
2498 location.hh, position.hh and stack.hh).
2500 *** Locations are no longer mandatory (lalr1.cc, glr.cc)
2502 Both lalr1.cc and glr.cc no longer require %location.
2504 *** syntax_error exception (lalr1.cc)
2506 The C++ parser features a syntax_error exception, which can be
2507 thrown from the scanner or from user rules to raise syntax errors.
2508 This facilitates reporting errors caught in sub-functions (e.g.,
2509 rejecting too large integral literals from a conversion function
2510 used by the scanner, or rejecting invalid combinations from a
2511 factory invoked by the user actions).
2513 *** %define api.value.type variant
2515 This is based on a submission from Michiel De Wilde. With help
2516 from Théophile Ranquet.
2518 In this mode, complex C++ objects can be used as semantic values. For
2521 %token <::std::string> TEXT;
2522 %token <int> NUMBER;
2523 %token SEMICOLON ";"
2524 %type <::std::string> item;
2525 %type <::std::list<std::string>> list;
2528 list { std::cout << $1 << std::endl; }
2532 %empty { /* Generates an empty string list. */ }
2533 | list item ";" { std::swap ($$, $1); $$.push_back ($2); }
2537 TEXT { std::swap ($$, $1); }
2538 | NUMBER { $$ = string_cast ($1); }
2541 *** %define api.token.constructor
2543 When variants are enabled, Bison can generate functions to build the
2544 tokens. This guarantees that the token type (e.g., NUMBER) is consistent
2545 with the semantic value (e.g., int):
2547 parser::symbol_type yylex ()
2549 parser::location_type loc = ...;
2551 return parser::make_TEXT ("Hello, world!", loc);
2553 return parser::make_NUMBER (42, loc);
2555 return parser::make_SEMICOLON (loc);
2561 There are operator- and operator-= for 'location'. Negative line/column
2562 increments can no longer underflow the resulting value.
2565 * Noteworthy changes in release 2.7.1 (2013-04-15) [stable]
2569 *** Fix compiler attribute portability (yacc.c)
2571 With locations enabled, __attribute__ was used unprotected.
2573 *** Fix some compiler warnings (lalr1.cc)
2576 * Noteworthy changes in release 2.7 (2012-12-12) [stable]
2580 Warnings about uninitialized yylloc in yyparse have been fixed.
2582 Restored C90 compliance (yet no report was ever made).
2584 ** Diagnostics are improved
2586 Contributed by Théophile Ranquet.
2588 *** Changes in the format of error messages
2590 This used to be the format of many error reports:
2592 input.y:2.7-12: %type redeclaration for exp
2593 input.y:1.7-12: previous declaration
2597 input.y:2.7-12: error: %type redeclaration for exp
2598 input.y:1.7-12: previous declaration
2600 *** New format for error reports: carets
2602 Caret errors have been added to Bison:
2604 input.y:2.7-12: error: %type redeclaration for exp
2607 input.y:1.7-12: previous declaration
2613 input.y:3.20-23: error: ambiguous reference: '$exp'
2614 exp: exp '+' exp { $exp = $1 + $3; };
2616 input.y:3.1-3: refers to: $exp at $$
2617 exp: exp '+' exp { $exp = $1 + $3; };
2619 input.y:3.6-8: refers to: $exp at $1
2620 exp: exp '+' exp { $exp = $1 + $3; };
2622 input.y:3.14-16: refers to: $exp at $3
2623 exp: exp '+' exp { $exp = $1 + $3; };
2626 The default behavior for now is still not to display these unless
2627 explicitly asked with -fcaret (or -fall). However, in a later release, it
2628 will be made the default behavior (but may still be deactivated with
2631 ** New value for %define variable: api.pure full
2633 The %define variable api.pure requests a pure (reentrant) parser. However,
2634 for historical reasons, using it in a location-tracking Yacc parser
2635 resulted in a yyerror function that did not take a location as a
2636 parameter. With this new value, the user may request a better pure parser,
2637 where yyerror does take a location as a parameter (in location-tracking
2640 The use of "%define api.pure true" is deprecated in favor of this new
2641 "%define api.pure full".
2643 ** New %define variable: api.location.type (glr.cc, lalr1.cc, lalr1.java)
2645 The %define variable api.location.type defines the name of the type to use
2646 for locations. When defined, Bison no longer generates the position.hh
2647 and location.hh files, nor does the parser will include them: the user is
2648 then responsible to define her type.
2650 This can be used in programs with several parsers to factor their location
2651 and position files: let one of them generate them, and the others just use
2654 This feature was actually introduced, but not documented, in Bison 2.5,
2655 under the name "location_type" (which is maintained for backward
2658 For consistency, lalr1.java's %define variables location_type and
2659 position_type are deprecated in favor of api.location.type and
2662 ** Exception safety (lalr1.cc)
2664 The parse function now catches exceptions, uses the %destructors to
2665 release memory (the lookahead symbol and the symbols pushed on the stack)
2666 before re-throwing the exception.
2668 This feature is somewhat experimental. User feedback would be
2671 ** Graph improvements in DOT and XSLT
2673 Contributed by Théophile Ranquet.
2675 The graphical presentation of the states is more readable: their shape is
2676 now rectangular, the state number is clearly displayed, and the items are
2677 numbered and left-justified.
2679 The reductions are now explicitly represented as transitions to other
2680 diamond shaped nodes.
2682 These changes are present in both --graph output and xml2dot.xsl XSLT
2683 processing, with minor (documented) differences.
2685 ** %language is no longer an experimental feature.
2687 The introduction of this feature, in 2.4, was four years ago. The
2688 --language option and the %language directive are no longer experimental.
2692 The sections about shift/reduce and reduce/reduce conflicts resolution
2693 have been fixed and extended.
2695 Although introduced more than four years ago, XML and Graphviz reports
2696 were not properly documented.
2698 The translation of midrule actions is now described.
2701 * Noteworthy changes in release 2.6.5 (2012-11-07) [stable]
2703 We consider compiler warnings about Bison generated parsers to be bugs.
2704 Rather than working around them in your own project, please consider
2705 reporting them to us.
2709 Warnings about uninitialized yylval and/or yylloc for push parsers with a
2710 pure interface have been fixed for GCC 4.0 up to 4.8, and Clang 2.9 to
2713 Other issues in the test suite have been addressed.
2715 Null characters are correctly displayed in error messages.
2717 When possible, yylloc is correctly initialized before calling yylex. It
2718 is no longer necessary to initialize it in the %initial-action.
2721 * Noteworthy changes in release 2.6.4 (2012-10-23) [stable]
2723 Bison 2.6.3's --version was incorrect. This release fixes this issue.
2726 * Noteworthy changes in release 2.6.3 (2012-10-22) [stable]
2730 Bugs and portability issues in the test suite have been fixed.
2732 Some errors in translations have been addressed, and --help now directs
2733 users to the appropriate place to report them.
2735 Stray Info files shipped by accident are removed.
2737 Incorrect definitions of YY_, issued by yacc.c when no parser header is
2738 generated, are removed.
2740 All the generated headers are self-contained.
2742 ** Header guards (yacc.c, glr.c, glr.cc)
2744 In order to avoid collisions, the header guards are now
2745 YY_<PREFIX>_<FILE>_INCLUDED, instead of merely <PREFIX>_<FILE>.
2746 For instance the header generated from
2748 %define api.prefix "calc"
2749 %defines "lib/parse.h"
2751 will use YY_CALC_LIB_PARSE_H_INCLUDED as guard.
2753 ** Fix compiler warnings in the generated parser (yacc.c, glr.c)
2755 The compilation of pure parsers (%define api.pure) can trigger GCC
2758 input.c: In function 'yyparse':
2759 input.c:1503:12: warning: 'yylval' may be used uninitialized in this
2760 function [-Wmaybe-uninitialized]
2764 This is now fixed; pragmas to avoid these warnings are no longer needed.
2766 Warnings from clang ("equality comparison with extraneous parentheses" and
2767 "function declared 'noreturn' should not return") have also been
2771 * Noteworthy changes in release 2.6.2 (2012-08-03) [stable]
2775 Buffer overruns, complaints from Flex, and portability issues in the test
2776 suite have been fixed.
2778 ** Spaces in %lex- and %parse-param (lalr1.cc, glr.cc)
2780 Trailing end-of-lines in %parse-param or %lex-param would result in
2781 invalid C++. This is fixed.
2783 ** Spurious spaces and end-of-lines
2785 The generated files no longer end (nor start) with empty lines.
2788 * Noteworthy changes in release 2.6.1 (2012-07-30) [stable]
2790 Bison no longer executes user-specified M4 code when processing a grammar.
2794 In addition to the removal of the features announced in Bison 2.6, the
2795 next major release will remove the "Temporary hack for adding a semicolon
2796 to the user action", as announced in the release 2.5. Instead of:
2798 exp: exp "+" exp { $$ = $1 + $3 };
2802 exp: exp "+" exp { $$ = $1 + $3; };
2806 *** Type names are now properly escaped.
2808 *** glr.cc: set_debug_level and debug_level work as expected.
2810 *** Stray @ or $ in actions
2812 While Bison used to warn about stray $ or @ in action rules, it did not
2813 for other actions such as printers, destructors, or initial actions. It
2816 ** Type names in actions
2818 For consistency with rule actions, it is now possible to qualify $$ by a
2819 type-name in destructors, printers, and initial actions. For instance:
2821 %printer { fprintf (yyo, "(%d, %f)", $<ival>$, $<fval>$); } <*> <>;
2823 will display two values for each typed and untyped symbol (provided
2824 that YYSTYPE has both "ival" and "fval" fields).
2827 * Noteworthy changes in release 2.6 (2012-07-19) [stable]
2831 The next major release of Bison will drop support for the following
2832 deprecated features. Please report disagreements to bug-bison@gnu.org.
2836 Support for generating parsers in K&R C will be removed. Parsers
2837 generated for C support ISO C90, and are tested with ISO C99 and ISO C11
2840 *** Features deprecated since Bison 1.875
2842 The definitions of yystype and yyltype will be removed; use YYSTYPE and
2845 YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and
2846 %lex-param, will no longer be supported.
2848 Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use
2851 *** The generated header will be included (yacc.c)
2853 Instead of duplicating the content of the generated header (definition of
2854 YYSTYPE, yyparse declaration etc.), the generated parser will include it,
2855 as is already the case for GLR or C++ parsers. This change is deferred
2856 because existing versions of ylwrap (e.g., Automake 1.12.1) do not support
2859 ** Generated Parser Headers
2861 *** Guards (yacc.c, glr.c, glr.cc)
2863 The generated headers are now guarded, as is already the case for C++
2864 parsers (lalr1.cc). For instance, with --defines=foo.h:
2869 #endif /* !YY_FOO_H */
2871 *** New declarations (yacc.c, glr.c)
2873 The generated header now declares yydebug and yyparse. Both honor
2874 --name-prefix=bar_, and yield
2876 int bar_parse (void);
2880 #define yyparse bar_parse
2883 in order to facilitate the inclusion of several parser headers inside a
2884 single compilation unit.
2886 *** Exported symbols in C++
2888 The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the
2889 header, are removed, as they prevent the possibility of including several
2890 generated headers from a single compilation unit.
2894 For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no
2897 ** New %define variable: api.prefix
2899 Now that the generated headers are more complete and properly protected
2900 against multiple inclusions, constant names, such as YYSTYPE are a
2901 problem. While yyparse and others are properly renamed by %name-prefix,
2902 YYSTYPE, YYDEBUG and others have never been affected by it. Because it
2903 would introduce backward compatibility issues in projects not expecting
2904 YYSTYPE to be renamed, instead of changing the behavior of %name-prefix,
2905 it is deprecated in favor of a new %define variable: api.prefix.
2907 The following examples compares both:
2909 %name-prefix "bar_" | %define api.prefix "bar_"
2910 %token <ival> FOO %token <ival> FOO
2911 %union { int ival; } %union { int ival; }
2917 #ifndef BAR_FOO_H #ifndef BAR_FOO_H
2918 # define BAR_FOO_H # define BAR_FOO_H
2920 /* Enabling traces. */ /* Enabling traces. */
2921 # ifndef YYDEBUG | # ifndef BAR_DEBUG
2922 > # if defined YYDEBUG
2924 > # define BAR_DEBUG 1
2926 > # define BAR_DEBUG 0
2929 # define YYDEBUG 0 | # define BAR_DEBUG 0
2933 # if YYDEBUG | # if BAR_DEBUG
2934 extern int bar_debug; extern int bar_debug;
2937 /* Tokens. */ /* Tokens. */
2938 # ifndef YYTOKENTYPE | # ifndef BAR_TOKENTYPE
2939 # define YYTOKENTYPE | # define BAR_TOKENTYPE
2940 enum yytokentype { | enum bar_tokentype {
2945 #if ! defined YYSTYPE \ | #if ! defined BAR_STYPE \
2946 && ! defined YYSTYPE_IS_DECLARED | && ! defined BAR_STYPE_IS_DECLARED
2947 typedef union YYSTYPE | typedef union BAR_STYPE
2950 } YYSTYPE; | } BAR_STYPE;
2951 # define YYSTYPE_IS_DECLARED 1 | # define BAR_STYPE_IS_DECLARED 1
2954 extern YYSTYPE bar_lval; | extern BAR_STYPE bar_lval;
2956 int bar_parse (void); int bar_parse (void);
2958 #endif /* !BAR_FOO_H */ #endif /* !BAR_FOO_H */
2961 * Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
2965 The next major release will drop support for generating parsers in K&R C.
2967 ** yacc.c: YYBACKUP works as expected.
2969 ** glr.c improvements:
2971 *** Location support is eliminated when not requested:
2973 GLR parsers used to include location-related code even when locations were
2974 not requested, and therefore not even usable.
2976 *** __attribute__ is preserved:
2978 __attribute__ is no longer disabled when __STRICT_ANSI__ is defined (i.e.,
2979 when -std is passed to GCC).
2981 ** lalr1.java: several fixes:
2983 The Java parser no longer throws ArrayIndexOutOfBoundsException if the
2984 first token leads to a syntax error. Some minor clean ups.
2988 *** C++11 compatibility:
2990 C and C++ parsers use "nullptr" instead of "0" when __cplusplus is 201103L
2995 The header files such as "parser.hh", "location.hh", etc. used a constant
2996 name for preprocessor guards, for instance:
2998 #ifndef BISON_LOCATION_HH
2999 # define BISON_LOCATION_HH
3001 #endif // !BISON_LOCATION_HH
3003 The inclusion guard is now computed from "PREFIX/FILE-NAME", where lower
3004 case characters are converted to upper case, and series of
3005 non-alphanumerical characters are converted to an underscore.
3007 With "bison -o lang++/parser.cc", "location.hh" would now include:
3009 #ifndef YY_LANG_LOCATION_HH
3010 # define YY_LANG_LOCATION_HH
3012 #endif // !YY_LANG_LOCATION_HH
3016 The position and location constructors (and their initialize methods)
3017 accept new arguments for line and column. Several issues in the
3018 documentation were fixed.
3020 ** liby is no longer asking for "rpl_fprintf" on some platforms.
3022 ** Changes in the manual:
3024 *** %printer is documented
3026 The "%printer" directive, supported since at least Bison 1.50, is finally
3027 documented. The "mfcalc" example is extended to demonstrate it.
3029 For consistency with the C skeletons, the C++ parsers now also support
3030 "yyoutput" (as an alias to "debug_stream ()").
3032 *** Several improvements have been made:
3034 The layout for grammar excerpts was changed to a more compact scheme.
3035 Named references are motivated. The description of the automaton
3036 description file (*.output) is updated to the current format. Incorrect
3037 index entries were fixed. Some other errors were fixed.
3041 *** Conflicting prototypes with recent/modified Flex.
3043 Fixed build problems with the current, unreleased, version of Flex, and
3044 some modified versions of 2.5.35, which have modified function prototypes.
3046 *** Warnings during the build procedure have been eliminated.
3048 *** Several portability problems in the test suite have been fixed:
3050 This includes warnings with some compilers, unexpected behavior of tools
3051 such as diff, warning messages from the test suite itself, etc.
3053 *** The install-pdf target works properly:
3055 Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
3056 halts in the middle of its course.
3059 * Noteworthy changes in release 2.5 (2011-05-14)
3061 ** Grammar symbol names can now contain non-initial dashes:
3063 Consistently with directives (such as %error-verbose) and with
3064 %define variables (e.g. push-pull), grammar symbol names may contain
3065 dashes in any position except the beginning. This is a GNU
3066 extension over POSIX Yacc. Thus, use of this extension is reported
3067 by -Wyacc and rejected in Yacc mode (--yacc).
3069 ** Named references:
3071 Historically, Yacc and Bison have supported positional references
3072 ($n, $$) to allow access to symbol values from inside of semantic
3075 Starting from this version, Bison can also accept named references.
3076 When no ambiguity is possible, original symbol names may be used
3077 as named references:
3079 if_stmt : "if" cond_expr "then" then_stmt ';'
3080 { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }
3082 In the more common case, explicit names may be declared:
3084 stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
3085 { $res = mk_if_stmt($cond, $then, $else); }
3087 Location information is also accessible using @name syntax. When
3088 accessing symbol names containing dots or dashes, explicit bracketing
3089 ($[sym.1]) must be used.
3091 These features are experimental in this version. More user feedback
3092 will help to stabilize them.
3093 Contributed by Alex Rozenman.
3095 ** IELR(1) and canonical LR(1):
3097 IELR(1) is a minimal LR(1) parser table generation algorithm. That
3098 is, given any context-free grammar, IELR(1) generates parser tables
3099 with the full language-recognition power of canonical LR(1) but with
3100 nearly the same number of parser states as LALR(1). This reduction
3101 in parser states is often an order of magnitude. More importantly,
3102 because canonical LR(1)'s extra parser states may contain duplicate
3103 conflicts in the case of non-LR(1) grammars, the number of conflicts
3104 for IELR(1) is often an order of magnitude less as well. This can
3105 significantly reduce the complexity of developing of a grammar.
3107 Bison can now generate IELR(1) and canonical LR(1) parser tables in
3108 place of its traditional LALR(1) parser tables, which remain the
3109 default. You can specify the type of parser tables in the grammar
3110 file with these directives:
3112 %define lr.type lalr
3113 %define lr.type ielr
3114 %define lr.type canonical-lr
3116 The default-reduction optimization in the parser tables can also be
3117 adjusted using "%define lr.default-reductions". For details on both
3118 of these features, see the new section "Tuning LR" in the Bison
3121 These features are experimental. More user feedback will help to
3124 ** LAC (Lookahead Correction) for syntax error handling
3126 Contributed by Joel E. Denny.
3128 Canonical LR, IELR, and LALR can suffer from a couple of problems
3129 upon encountering a syntax error. First, the parser might perform
3130 additional parser stack reductions before discovering the syntax
3131 error. Such reductions can perform user semantic actions that are
3132 unexpected because they are based on an invalid token, and they
3133 cause error recovery to begin in a different syntactic context than
3134 the one in which the invalid token was encountered. Second, when
3135 verbose error messages are enabled (with %error-verbose or the
3136 obsolete "#define YYERROR_VERBOSE"), the expected token list in the
3137 syntax error message can both contain invalid tokens and omit valid
3140 The culprits for the above problems are %nonassoc, default
3141 reductions in inconsistent states, and parser state merging. Thus,
3142 IELR and LALR suffer the most. Canonical LR can suffer only if
3143 %nonassoc is used or if default reductions are enabled for
3144 inconsistent states.
3146 LAC is a new mechanism within the parsing algorithm that solves
3147 these problems for canonical LR, IELR, and LALR without sacrificing
3148 %nonassoc, default reductions, or state merging. When LAC is in
3149 use, canonical LR and IELR behave almost exactly the same for both
3150 syntactically acceptable and syntactically unacceptable input.
3151 While LALR still does not support the full language-recognition
3152 power of canonical LR and IELR, LAC at least enables LALR's syntax
3153 error handling to correctly reflect LALR's language-recognition
3156 Currently, LAC is only supported for deterministic parsers in C.
3157 You can enable LAC with the following directive:
3159 %define parse.lac full
3161 See the new section "LAC" in the Bison manual for additional
3162 details including a few caveats.
3164 LAC is an experimental feature. More user feedback will help to
3167 ** %define improvements:
3169 *** Can now be invoked via the command line:
3171 Each of these command-line options
3174 --define=NAME[=VALUE]
3177 --force-define=NAME[=VALUE]
3179 is equivalent to this grammar file declaration
3181 %define NAME ["VALUE"]
3183 except that the manner in which Bison processes multiple definitions
3184 for the same NAME differs. Most importantly, -F and --force-define
3185 quietly override %define, but -D and --define do not. For further
3186 details, see the section "Bison Options" in the Bison manual.
3188 *** Variables renamed:
3190 The following %define variables
3193 lr.keep_unreachable_states
3195 have been renamed to
3198 lr.keep-unreachable-states
3200 The old names are now deprecated but will be maintained indefinitely
3201 for backward compatibility.
3203 *** Values no longer need to be quoted in the grammar file:
3205 If a %define value is an identifier, it no longer needs to be placed
3206 within quotations marks. For example,
3208 %define api.push-pull "push"
3212 %define api.push-pull push
3214 *** Unrecognized variables are now errors not warnings.
3216 *** Multiple invocations for any variable is now an error not a warning.
3218 ** Unrecognized %code qualifiers are now errors not warnings.
3220 ** Character literals not of length one:
3222 Previously, Bison quietly converted all character literals to length
3223 one. For example, without warning, Bison interpreted the operators in
3224 the following grammar to be the same token:
3230 Bison now warns when a character literal is not of length one. In
3231 some future release, Bison will start reporting an error instead.
3233 ** Destructor calls fixed for lookaheads altered in semantic actions:
3235 Previously for deterministic parsers in C, if a user semantic action
3236 altered yychar, the parser in some cases used the old yychar value to
3237 determine which destructor to call for the lookahead upon a syntax
3238 error or upon parser return. This bug has been fixed.
3240 ** C++ parsers use YYRHSLOC:
3242 Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
3243 macro and use it in the default YYLLOC_DEFAULT. You are encouraged
3244 to use it. If, for instance, your location structure has "first"
3245 and "last" members, instead of
3247 # define YYLLOC_DEFAULT(Current, Rhs, N) \
3251 (Current).first = (Rhs)[1].location.first; \
3252 (Current).last = (Rhs)[N].location.last; \
3256 (Current).first = (Current).last = (Rhs)[0].location.last; \
3262 # define YYLLOC_DEFAULT(Current, Rhs, N) \
3266 (Current).first = YYRHSLOC (Rhs, 1).first; \
3267 (Current).last = YYRHSLOC (Rhs, N).last; \
3271 (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last; \
3275 ** YYLLOC_DEFAULT in C++:
3277 The default implementation of YYLLOC_DEFAULT used to be issued in
3278 the header file. It is now output in the implementation file, after
3279 the user %code sections so that its #ifndef guard does not try to
3280 override the user's YYLLOC_DEFAULT if provided.
3282 ** YYFAIL now produces warnings and Java parsers no longer implement it:
3284 YYFAIL has existed for many years as an undocumented feature of
3285 deterministic parsers in C generated by Bison. More recently, it was
3286 a documented feature of Bison's experimental Java parsers. As
3287 promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
3288 semantic action now produces a deprecation warning, and Java parsers
3289 no longer implement YYFAIL at all. For further details, including a
3290 discussion of how to suppress C preprocessor warnings about YYFAIL
3291 being unused, see the Bison 2.4.2 NEWS entry.
3293 ** Temporary hack for adding a semicolon to the user action:
3295 Previously, Bison appended a semicolon to every user action for
3296 reductions when the output language defaulted to C (specifically, when
3297 neither %yacc, %language, %skeleton, or equivalent command-line
3298 options were specified). This allowed actions such as
3300 exp: exp "+" exp { $$ = $1 + $3 };
3304 exp: exp "+" exp { $$ = $1 + $3; };
3306 As a first step in removing this misfeature, Bison now issues a
3307 warning when it appends a semicolon. Moreover, in cases where Bison
3308 cannot easily determine whether a semicolon is needed (for example, an
3309 action ending with a cpp directive or a braced compound initializer),
3310 it no longer appends one. Thus, the C compiler might now complain
3311 about a missing semicolon where it did not before. Future releases of
3312 Bison will cease to append semicolons entirely.
3314 ** Verbose syntax error message fixes:
3316 When %error-verbose or the obsolete "#define YYERROR_VERBOSE" is
3317 specified, syntax error messages produced by the generated parser
3318 include the unexpected token as well as a list of expected tokens.
3319 The effect of %nonassoc on these verbose messages has been corrected
3320 in two ways, but a more complete fix requires LAC, described above:
3322 *** When %nonassoc is used, there can exist parser states that accept no
3323 tokens, and so the parser does not always require a lookahead token
3324 in order to detect a syntax error. Because no unexpected token or
3325 expected tokens can then be reported, the verbose syntax error
3326 message described above is suppressed, and the parser instead
3327 reports the simpler message, "syntax error". Previously, this
3328 suppression was sometimes erroneously triggered by %nonassoc when a
3329 lookahead was actually required. Now verbose messages are
3330 suppressed only when all previous lookaheads have already been
3331 shifted or discarded.
3333 *** Previously, the list of expected tokens erroneously included tokens
3334 that would actually induce a syntax error because conflicts for them
3335 were resolved with %nonassoc in the current parser state. Such
3336 tokens are now properly omitted from the list.
3338 *** Expected token lists are still often wrong due to state merging
3339 (from LALR or IELR) and default reductions, which can both add
3340 invalid tokens and subtract valid tokens. Canonical LR almost
3341 completely fixes this problem by eliminating state merging and
3342 default reductions. However, there is one minor problem left even
3343 when using canonical LR and even after the fixes above. That is,
3344 if the resolution of a conflict with %nonassoc appears in a later
3345 parser state than the one at which some syntax error is
3346 discovered, the conflicted token is still erroneously included in
3347 the expected token list. Bison's new LAC implementation,
3348 described above, eliminates this problem and the need for
3349 canonical LR. However, LAC is still experimental and is disabled
3352 ** Java skeleton fixes:
3354 *** A location handling bug has been fixed.
3356 *** The top element of each of the value stack and location stack is now
3357 cleared when popped so that it can be garbage collected.
3359 *** Parser traces now print the top element of the stack.
3361 ** -W/--warnings fixes:
3363 *** Bison now properly recognizes the "no-" versions of categories:
3365 For example, given the following command line, Bison now enables all
3366 warnings except warnings for incompatibilities with POSIX Yacc:
3368 bison -Wall,no-yacc gram.y
3370 *** Bison now treats S/R and R/R conflicts like other warnings:
3372 Previously, conflict reports were independent of Bison's normal
3373 warning system. Now, Bison recognizes the warning categories
3374 "conflicts-sr" and "conflicts-rr". This change has important
3375 consequences for the -W and --warnings command-line options. For
3378 bison -Wno-conflicts-sr gram.y # S/R conflicts not reported
3379 bison -Wno-conflicts-rr gram.y # R/R conflicts not reported
3380 bison -Wnone gram.y # no conflicts are reported
3381 bison -Werror gram.y # any conflict is an error
3383 However, as before, if the %expect or %expect-rr directive is
3384 specified, an unexpected number of conflicts is an error, and an
3385 expected number of conflicts is not reported, so -W and --warning
3386 then have no effect on the conflict report.
3388 *** The "none" category no longer disables a preceding "error":
3390 For example, for the following command line, Bison now reports
3391 errors instead of warnings for incompatibilities with POSIX Yacc:
3393 bison -Werror,none,yacc gram.y
3395 *** The "none" category now disables all Bison warnings:
3397 Previously, the "none" category disabled only Bison warnings for
3398 which there existed a specific -W/--warning category. However,
3399 given the following command line, Bison is now guaranteed to
3400 suppress all warnings:
3404 ** Precedence directives can now assign token number 0:
3406 Since Bison 2.3b, which restored the ability of precedence
3407 directives to assign token numbers, doing so for token number 0 has
3408 produced an assertion failure. For example:
3412 This bug has been fixed.
3415 * Noteworthy changes in release 2.4.3 (2010-08-05)
3417 ** Bison now obeys -Werror and --warnings=error for warnings about
3418 grammar rules that are useless in the parser due to conflicts.
3420 ** Problems with spawning M4 on at least FreeBSD 8 and FreeBSD 9 have
3423 ** Failures in the test suite for GCC 4.5 have been fixed.
3425 ** Failures in the test suite for some versions of Sun Studio C++ have
3428 ** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
3429 warnings about undefined %prec identifiers will not be converted to
3430 errors in Bison 2.5. They will remain warnings, which should be
3431 sufficient for POSIX while avoiding backward compatibility issues.
3433 ** Minor documentation fixes.
3436 * Noteworthy changes in release 2.4.2 (2010-03-20)
3438 ** Some portability problems that resulted in failures and livelocks
3439 in the test suite on some versions of at least Solaris, AIX, HP-UX,
3440 RHEL4, and Tru64 have been addressed. As a result, fatal Bison
3441 errors should no longer cause M4 to report a broken pipe on the
3444 ** "%prec IDENTIFIER" requires IDENTIFIER to be defined separately.
3446 POSIX specifies that an error be reported for any identifier that does
3447 not appear on the LHS of a grammar rule and that is not defined by
3448 %token, %left, %right, or %nonassoc. Bison 2.3b and later lost this
3449 error report for the case when an identifier appears only after a
3450 %prec directive. It is now restored. However, for backward
3451 compatibility with recent Bison releases, it is only a warning for
3452 now. In Bison 2.5 and later, it will return to being an error.
3453 [Between the 2.4.2 and 2.4.3 releases, it was decided that this
3454 warning will not be converted to an error in Bison 2.5.]
3456 ** Detection of GNU M4 1.4.6 or newer during configure is improved.
3458 ** Warnings from gcc's -Wundef option about undefined YYENABLE_NLS,
3459 YYLTYPE_IS_TRIVIAL, and __STRICT_ANSI__ in C/C++ parsers are now
3462 ** %code is now a permanent feature.
3464 A traditional Yacc prologue directive is written in the form:
3468 To provide a more flexible alternative, Bison 2.3b introduced the
3469 %code directive with the following forms for C/C++:
3472 %code requires {CODE}
3473 %code provides {CODE}
3476 These forms are now considered permanent features of Bison. See the
3477 %code entries in the section "Bison Declaration Summary" in the Bison
3478 manual for a summary of their functionality. See the section
3479 "Prologue Alternatives" for a detailed discussion including the
3480 advantages of %code over the traditional Yacc prologue directive.
3482 Bison's Java feature as a whole including its current usage of %code
3483 is still considered experimental.
3485 ** YYFAIL is deprecated and will eventually be removed.
3487 YYFAIL has existed for many years as an undocumented feature of
3488 deterministic parsers in C generated by Bison. Previously, it was
3489 documented for Bison's experimental Java parsers. YYFAIL is no longer
3490 documented for Java parsers and is formally deprecated in both cases.
3491 Users are strongly encouraged to migrate to YYERROR, which is
3494 Like YYERROR, you can invoke YYFAIL from a semantic action in order to
3495 induce a syntax error. The most obvious difference from YYERROR is
3496 that YYFAIL will automatically invoke yyerror to report the syntax
3497 error so that you don't have to. However, there are several other
3498 subtle differences between YYERROR and YYFAIL, and YYFAIL suffers from
3499 inherent flaws when %error-verbose or "#define YYERROR_VERBOSE" is
3500 used. For a more detailed discussion, see:
3502 https://lists.gnu.org/r/bison-patches/2009-12/msg00024.html
3504 The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but
3505 deterministic parsers in C will continue to implement it. However,
3506 because YYFAIL is already flawed, it seems futile to try to make new
3507 Bison features compatible with it. Thus, during parser generation,
3508 Bison 2.5 will produce a warning whenever it discovers YYFAIL in a
3509 rule action. In a later release, YYFAIL will be disabled for
3510 %error-verbose and "#define YYERROR_VERBOSE". Eventually, YYFAIL will
3511 be removed altogether.
3513 There exists at least one case where Bison 2.5's YYFAIL warning will
3514 be a false positive. Some projects add phony uses of YYFAIL and other
3515 Bison-defined macros for the sole purpose of suppressing C
3516 preprocessor warnings (from GCC cpp's -Wunused-macros, for example).
3517 To avoid Bison's future warning, such YYFAIL uses can be moved to the
3518 epilogue (that is, after the second "%%") in the Bison input file. In
3519 this release (2.4.2), Bison already generates its own code to suppress
3520 C preprocessor warnings for YYFAIL, so projects can remove their own
3521 phony uses of YYFAIL if compatibility with Bison releases prior to
3522 2.4.2 is not necessary.
3524 ** Internationalization.
3526 Fix a regression introduced in Bison 2.4: Under some circumstances,
3527 message translations were not installed although supported by the
3531 * Noteworthy changes in release 2.4.1 (2008-12-11)
3533 ** In the GLR defines file, unexpanded M4 macros in the yylval and yylloc
3534 declarations have been fixed.
3536 ** Temporary hack for adding a semicolon to the user action.
3538 Bison used to prepend a trailing semicolon at the end of the user
3539 action for reductions. This allowed actions such as
3541 exp: exp "+" exp { $$ = $1 + $3 };
3545 exp: exp "+" exp { $$ = $1 + $3; };
3547 Some grammars still depend on this "feature". Bison 2.4.1 restores
3548 the previous behavior in the case of C output (specifically, when
3549 neither %language or %skeleton or equivalent command-line options
3550 are used) to leave more time for grammars depending on the old
3551 behavior to be adjusted. Future releases of Bison will disable this
3554 ** A few minor improvements to the Bison manual.
3557 * Noteworthy changes in release 2.4 (2008-11-02)
3559 ** %language is an experimental feature.
3561 We first introduced this feature in test release 2.3b as a cleaner
3562 alternative to %skeleton. Since then, we have discussed the possibility of
3563 modifying its effect on Bison's output file names. Thus, in this release,
3564 we consider %language to be an experimental feature that will likely evolve
3567 ** Forward compatibility with GNU M4 has been improved.
3569 ** Several bugs in the C++ skeleton and the experimental Java skeleton have been
3573 * Noteworthy changes in release 2.3b (2008-05-27)
3575 ** The quotes around NAME that used to be required in the following directive
3578 %define NAME "VALUE"
3580 ** The directive "%pure-parser" is now deprecated in favor of:
3584 which has the same effect except that Bison is more careful to warn about
3585 unreasonable usage in the latter case.
3589 Bison can now generate an LALR(1) parser in C with a push interface. That
3590 is, instead of invoking "yyparse", which pulls tokens from "yylex", you can
3591 push one token at a time to the parser using "yypush_parse", which will
3592 return to the caller after processing each token. By default, the push
3593 interface is disabled. Either of the following directives will enable it:
3595 %define api.push_pull "push" // Just push; does not require yylex.
3596 %define api.push_pull "both" // Push and pull; requires yylex.
3598 See the new section "A Push Parser" in the Bison manual for details.
3600 The current push parsing interface is experimental and may evolve. More user
3601 feedback will help to stabilize it.
3603 ** The -g and --graph options now output graphs in Graphviz DOT format,
3604 not VCG format. Like --graph, -g now also takes an optional FILE argument
3605 and thus cannot be bundled with other short options.
3609 Bison can now generate an LALR(1) parser in Java. The skeleton is
3610 "data/lalr1.java". Consider using the new %language directive instead of
3611 %skeleton to select it.
3613 See the new section "Java Parsers" in the Bison manual for details.
3615 The current Java interface is experimental and may evolve. More user
3616 feedback will help to stabilize it.
3617 Contributed by Paolo Bonzini.
3621 This new directive specifies the programming language of the generated
3622 parser, which can be C (the default), C++, or Java. Besides the skeleton
3623 that Bison uses, the directive affects the names of the generated files if
3624 the grammar file's name ends in ".y".
3626 ** XML Automaton Report
3628 Bison can now generate an XML report of the LALR(1) automaton using the new
3629 "--xml" option. The current XML schema is experimental and may evolve. More
3630 user feedback will help to stabilize it.
3631 Contributed by Wojciech Polak.
3633 ** The grammar file may now specify the name of the parser header file using
3634 %defines. For example:
3638 ** When reporting useless rules, useless nonterminals, and unused terminals,
3639 Bison now employs the terms "useless in grammar" instead of "useless",
3640 "useless in parser" instead of "never reduced", and "unused in grammar"
3641 instead of "unused".
3643 ** Unreachable State Removal
3645 Previously, Bison sometimes generated parser tables containing unreachable
3646 states. A state can become unreachable during conflict resolution if Bison
3647 disables a shift action leading to it from a predecessor state. Bison now:
3649 1. Removes unreachable states.
3651 2. Does not report any conflicts that appeared in unreachable states.
3652 WARNING: As a result, you may need to update %expect and %expect-rr
3653 directives in existing grammar files.
3655 3. For any rule used only in such states, Bison now reports the rule as
3656 "useless in parser due to conflicts".
3658 This feature can be disabled with the following directive:
3660 %define lr.keep_unreachable_states
3662 See the %define entry in the "Bison Declaration Summary" in the Bison manual
3663 for further discussion.
3665 ** Lookahead Set Correction in the ".output" Report
3667 When instructed to generate a ".output" file including lookahead sets
3668 (using "--report=lookahead", for example), Bison now prints each reduction's
3669 lookahead set only next to the associated state's one item that (1) is
3670 associated with the same rule as the reduction and (2) has its dot at the end
3671 of its RHS. Previously, Bison also erroneously printed the lookahead set
3672 next to all of the state's other items associated with the same rule. This
3673 bug affected only the ".output" file and not the generated parser source
3676 ** --report-file=FILE is a new option to override the default ".output" file
3679 ** The "=" that used to be required in the following directives is now
3682 %file-prefix "parser"
3686 ** An Alternative to "%{...%}" -- "%code QUALIFIER {CODE}"
3688 Bison 2.3a provided a new set of directives as a more flexible alternative to
3689 the traditional Yacc prologue blocks. Those have now been consolidated into
3690 a single %code directive with an optional qualifier field, which identifies
3691 the purpose of the code and thus the location(s) where Bison should generate
3694 1. "%code {CODE}" replaces "%after-header {CODE}"
3695 2. "%code requires {CODE}" replaces "%start-header {CODE}"
3696 3. "%code provides {CODE}" replaces "%end-header {CODE}"
3697 4. "%code top {CODE}" replaces "%before-header {CODE}"
3699 See the %code entries in section "Bison Declaration Summary" in the Bison
3700 manual for a summary of the new functionality. See the new section "Prologue
3701 Alternatives" for a detailed discussion including the advantages of %code
3702 over the traditional Yacc prologues.
3704 The prologue alternatives are experimental. More user feedback will help to
3705 determine whether they should become permanent features.
3707 ** Revised warning: unset or unused midrule values
3709 Since Bison 2.2, Bison has warned about midrule values that are set but not
3710 used within any of the actions of the parent rule. For example, Bison warns
3713 exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };
3715 Now, Bison also warns about midrule values that are used but not set. For
3716 example, Bison warns about unset $$ in the midrule action in:
3718 exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };
3720 However, Bison now disables both of these warnings by default since they
3721 sometimes prove to be false alarms in existing grammars employing the Yacc
3722 constructs $0 or $-N (where N is some positive integer).
3724 To enable these warnings, specify the option "--warnings=midrule-values" or
3725 "-W", which is a synonym for "--warnings=all".
3727 ** Default %destructor or %printer with "<*>" or "<>"
3729 Bison now recognizes two separate kinds of default %destructor's and
3732 1. Place "<*>" in a %destructor/%printer symbol list to define a default
3733 %destructor/%printer for all grammar symbols for which you have formally
3734 declared semantic type tags.
3736 2. Place "<>" in a %destructor/%printer symbol list to define a default
3737 %destructor/%printer for all grammar symbols without declared semantic
3740 Bison no longer supports the "%symbol-default" notation from Bison 2.3a.
3741 "<*>" and "<>" combined achieve the same effect with one exception: Bison no
3742 longer applies any %destructor to a midrule value if that midrule value is
3743 not actually ever referenced using either $$ or $n in a semantic action.
3745 The default %destructor's and %printer's are experimental. More user
3746 feedback will help to determine whether they should become permanent
3749 See the section "Freeing Discarded Symbols" in the Bison manual for further
3752 ** %left, %right, and %nonassoc can now declare token numbers. This is required
3753 by POSIX. However, see the end of section "Operator Precedence" in the Bison
3754 manual for a caveat concerning the treatment of literal strings.
3756 ** The nonfunctional --no-parser, -n, and %no-parser options have been
3757 completely removed from Bison.
3760 * Noteworthy changes in release 2.3a (2006-09-13)
3762 ** Instead of %union, you can define and use your own union type
3763 YYSTYPE if your grammar contains at least one <type> tag.
3764 Your YYSTYPE need not be a macro; it can be a typedef.
3765 This change is for compatibility with other Yacc implementations,
3766 and is required by POSIX.
3768 ** Locations columns and lines start at 1.
3769 In accordance with the GNU Coding Standards and Emacs.
3771 ** You may now declare per-type and default %destructor's and %printer's:
3775 %union { char *string; }
3776 %token <string> STRING1
3777 %token <string> STRING2
3778 %type <string> string1
3779 %type <string> string2
3780 %union { char character; }
3781 %token <character> CHR
3782 %type <character> chr
3783 %destructor { free ($$); } %symbol-default
3784 %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
3785 %destructor { } <character>
3787 guarantees that, when the parser discards any user-defined symbol that has a
3788 semantic type tag other than "<character>", it passes its semantic value to
3789 "free". However, when the parser discards a "STRING1" or a "string1", it
3790 also prints its line number to "stdout". It performs only the second
3791 "%destructor" in this case, so it invokes "free" only once.
3793 [Although we failed to mention this here in the 2.3a release, the default
3794 %destructor's and %printer's were experimental, and they were rewritten in
3797 ** Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with "-y",
3798 "--yacc", or "%yacc"), Bison no longer generates #define statements for
3799 associating token numbers with token names. Removing the #define statements
3800 helps to sanitize the global namespace during preprocessing, but POSIX Yacc
3801 requires them. Bison still generates an enum for token names in all cases.
3803 ** Handling of traditional Yacc prologue blocks is now more consistent but
3804 potentially incompatible with previous releases of Bison.
3806 As before, you declare prologue blocks in your grammar file with the
3807 "%{ ... %}" syntax. To generate the pre-prologue, Bison concatenates all
3808 prologue blocks that you've declared before the first %union. To generate
3809 the post-prologue, Bison concatenates all prologue blocks that you've
3810 declared after the first %union.
3812 Previous releases of Bison inserted the pre-prologue into both the header
3813 file and the code file in all cases except for LALR(1) parsers in C. In the
3814 latter case, Bison inserted it only into the code file. For parsers in C++,
3815 the point of insertion was before any token definitions (which associate
3816 token numbers with names). For parsers in C, the point of insertion was
3817 after the token definitions.
3819 Now, Bison never inserts the pre-prologue into the header file. In the code
3820 file, it always inserts it before the token definitions.
3822 ** Bison now provides a more flexible alternative to the traditional Yacc
3823 prologue blocks: %before-header, %start-header, %end-header, and
3826 For example, the following declaration order in the grammar file reflects the
3827 order in which Bison will output these code blocks. However, you are free to
3828 declare these code blocks in your grammar file in whatever order is most
3832 /* Bison treats this block like a pre-prologue block: it inserts it into
3833 * the code file before the contents of the header file. It does *not*
3834 * insert it into the header file. This is a good place to put
3835 * #include's that you want at the top of your code file. A common
3836 * example is '#include "system.h"'. */
3839 /* Bison inserts this block into both the header file and the code file.
3840 * In both files, the point of insertion is before any Bison-generated
3841 * token, semantic type, location type, and class definitions. This is a
3842 * good place to define %union dependencies, for example. */
3845 /* Unlike the traditional Yacc prologue blocks, the output order for the
3846 * new %*-header blocks is not affected by their declaration position
3847 * relative to any %union in the grammar file. */
3850 /* Bison inserts this block into both the header file and the code file.
3851 * In both files, the point of insertion is after the Bison-generated
3852 * definitions. This is a good place to declare or define public
3853 * functions or data structures that depend on the Bison-generated
3857 /* Bison treats this block like a post-prologue block: it inserts it into
3858 * the code file after the contents of the header file. It does *not*
3859 * insert it into the header file. This is a good place to declare or
3860 * define internal functions or data structures that depend on the
3861 * Bison-generated definitions. */
3864 If you have multiple occurrences of any one of the above declarations, Bison
3865 will concatenate the contents in declaration order.
3867 [Although we failed to mention this here in the 2.3a release, the prologue
3868 alternatives were experimental, and they were rewritten in future versions.]
3870 ** The option "--report=look-ahead" has been changed to "--report=lookahead".
3871 The old spelling still works, but is not documented and may be removed
3872 in a future release.
3875 * Noteworthy changes in release 2.3 (2006-06-05)
3877 ** GLR grammars should now use "YYRECOVERING ()" instead of "YYRECOVERING",
3878 for compatibility with LALR(1) grammars.
3880 ** It is now documented that any definition of YYSTYPE or YYLTYPE should
3881 be to a type name that does not contain parentheses or brackets.
3884 * Noteworthy changes in release 2.2 (2006-05-19)
3886 ** The distribution terms for all Bison-generated parsers now permit
3887 using the parsers in nonfree programs. Previously, this permission
3888 was granted only for Bison-generated LALR(1) parsers in C.
3890 ** %name-prefix changes the namespace name in C++ outputs.
3892 ** The C++ parsers export their token_type.
3894 ** Bison now allows multiple %union declarations, and concatenates
3895 their contents together.
3897 ** New warning: unused values
3898 Right-hand side symbols whose values are not used are reported,
3899 if the symbols have destructors. For instance:
3901 exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
3905 will trigger a warning about $$ and $5 in the first rule, and $3 in
3906 the second ($1 is copied to $$ by the default rule). This example
3907 most likely contains three errors, and could be rewritten as:
3909 exp: exp "?" exp ":" exp
3910 { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
3912 { $$ = $1 ? $1 : $3; if ($1) free ($3); }
3915 However, if the original actions were really intended, memory leaks
3916 and all, the warnings can be suppressed by letting Bison believe the
3917 values are used, e.g.:
3919 exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
3920 | exp "+" exp { $$ = $1; (void) $3; }
3923 If there are midrule actions, the warning is issued if no action
3924 uses it. The following triggers no warning: $1 and $3 are used.
3926 exp: exp { push ($1); } '+' exp { push ($3); sum (); };
3928 The warning is intended to help catching lost values and memory leaks.
3929 If a value is ignored, its associated memory typically is not reclaimed.
3931 ** %destructor vs. YYABORT, YYACCEPT, and YYERROR.
3932 Destructors are now called when user code invokes YYABORT, YYACCEPT,
3933 and YYERROR, for all objects on the stack, other than objects
3934 corresponding to the right-hand side of the current rule.
3936 ** %expect, %expect-rr
3937 Incorrect numbers of expected conflicts are now actual errors,
3938 instead of warnings.
3940 ** GLR, YACC parsers.
3941 The %parse-params are available in the destructors (and the
3942 experimental printers) as per the documentation.
3944 ** Bison now warns if it finds a stray "$" or "@" in an action.
3946 ** %require "VERSION"
3947 This specifies that the grammar file depends on features implemented
3948 in Bison version VERSION or higher.
3950 ** lalr1.cc: The token and value types are now class members.
3951 The tokens were defined as free form enums and cpp macros. YYSTYPE
3952 was defined as a free form union. They are now class members:
3953 tokens are enumerations of the "yy::parser::token" struct, and the
3954 semantic values have the "yy::parser::semantic_type" type.
3956 If you do not want or can update to this scheme, the directive
3957 '%define "global_tokens_and_yystype" "1"' triggers the global
3958 definition of tokens and YYSTYPE. This change is suitable both
3959 for previous releases of Bison, and this one.
3961 If you wish to update, then make sure older version of Bison will
3962 fail using '%require "2.2"'.
3964 ** DJGPP support added.
3967 * Noteworthy changes in release 2.1 (2005-09-16)
3969 ** The C++ lalr1.cc skeleton supports %lex-param.
3971 ** Bison-generated parsers now support the translation of diagnostics like
3972 "syntax error" into languages other than English. The default
3973 language is still English. For details, please see the new
3974 Internationalization section of the Bison manual. Software
3975 distributors should also see the new PACKAGING file. Thanks to
3976 Bruno Haible for this new feature.
3978 ** Wording in the Bison-generated parsers has been changed slightly to
3979 simplify translation. In particular, the message "memory exhausted"
3980 has replaced "parser stack overflow", as the old message was not
3981 always accurate for modern Bison-generated parsers.
3983 ** Destructors are now called when the parser aborts, for all symbols left
3984 behind on the stack. Also, the start symbol is now destroyed after a
3985 successful parse. In both cases, the behavior was formerly inconsistent.
3987 ** When generating verbose diagnostics, Bison-generated parsers no longer
3988 quote the literal strings associated with tokens. For example, for
3989 a syntax error associated with '%token NUM "number"' they might
3990 print 'syntax error, unexpected number' instead of 'syntax error,
3991 unexpected "number"'.
3994 * Noteworthy changes in release 2.0 (2004-12-25)
3996 ** Possibly-incompatible changes
3998 - Bison-generated parsers no longer default to using the alloca function
3999 (when available) to extend the parser stack, due to widespread
4000 problems in unchecked stack-overflow detection. You can "#define
4001 YYSTACK_USE_ALLOCA 1" to require the use of alloca, but please read
4002 the manual to determine safe values for YYMAXDEPTH in that case.
4004 - Error token location.
4005 During error recovery, the location of the syntax error is updated
4006 to cover the whole sequence covered by the error token: it includes
4007 the shifted symbols thrown away during the first part of the error
4008 recovery, and the lookahead rejected during the second part.
4010 - Semicolon changes:
4011 . Stray semicolons are no longer allowed at the start of a grammar.
4012 . Semicolons are now required after in-grammar declarations.
4014 - Unescaped newlines are no longer allowed in character constants or
4015 string literals. They were never portable, and GCC 3.4.0 has
4016 dropped support for them. Better diagnostics are now generated if
4017 forget a closing quote.
4019 - NUL bytes are no longer allowed in Bison string literals, unfortunately.
4023 - GLR grammars now support locations.
4025 - New directive: %initial-action.
4026 This directive allows the user to run arbitrary code (including
4027 initializing @$) from yyparse before parsing starts.
4029 - A new directive "%expect-rr N" specifies the expected number of
4030 reduce/reduce conflicts in GLR parsers.
4032 - %token numbers can now be hexadecimal integers, e.g., "%token FOO 0x12d".
4033 This is a GNU extension.
4035 - The option "--report=lookahead" was changed to "--report=look-ahead".
4036 [However, this was changed back after 2.3.]
4038 - Experimental %destructor support has been added to lalr1.cc.
4040 - New configure option --disable-yacc, to disable installation of the
4041 yacc command and -ly library introduced in 1.875 for POSIX conformance.
4045 - For now, %expect-count violations are now just warnings, not errors.
4046 This is for compatibility with Bison 1.75 and earlier (when there are
4047 reduce/reduce conflicts) and with Bison 1.30 and earlier (when there
4048 are too many or too few shift/reduce conflicts). However, in future
4049 versions of Bison we plan to improve the %expect machinery so that
4050 these violations will become errors again.
4052 - Within Bison itself, numbers (e.g., goto numbers) are no longer
4053 arbitrarily limited to 16-bit counts.
4055 - Semicolons are now allowed before "|" in grammar rules, as POSIX requires.
4058 * Noteworthy changes in release 1.875 (2003-01-01)
4060 ** The documentation license has been upgraded to version 1.2
4061 of the GNU Free Documentation License.
4063 ** syntax error processing
4065 - In Yacc-style parsers YYLLOC_DEFAULT is now used to compute error
4066 locations too. This fixes bugs in error-location computation.
4069 It is now possible to reclaim the memory associated to symbols
4070 discarded during error recovery. This feature is still experimental.
4073 This new directive is preferred over YYERROR_VERBOSE.
4075 - #defining yyerror to steal internal variables is discouraged.
4076 It is not guaranteed to work forever.
4078 ** POSIX conformance
4080 - Semicolons are once again optional at the end of grammar rules.
4081 This reverts to the behavior of Bison 1.33 and earlier, and improves
4082 compatibility with Yacc.
4084 - "parse error" -> "syntax error"
4085 Bison now uniformly uses the term "syntax error"; formerly, the code
4086 and manual sometimes used the term "parse error" instead. POSIX
4087 requires "syntax error" in diagnostics, and it was thought better to
4090 - The documentation now emphasizes that yylex and yyerror must be
4091 declared before use. C99 requires this.
4093 - Bison now parses C99 lexical constructs like UCNs and
4094 backslash-newline within C escape sequences, as POSIX 1003.1-2001 requires.
4096 - File names are properly escaped in C output. E.g., foo\bar.y is
4097 output as "foo\\bar.y".
4099 - Yacc command and library now available
4100 The Bison distribution now installs a "yacc" command, as POSIX requires.
4101 Also, Bison now installs a small library liby.a containing
4102 implementations of Yacc-compatible yyerror and main functions.
4103 This library is normally not useful, but POSIX requires it.
4105 - Type clashes now generate warnings, not errors.
4107 - If the user does not define YYSTYPE as a macro, Bison now declares it
4108 using typedef instead of defining it as a macro.
4109 For consistency, YYLTYPE is also declared instead of defined.
4111 ** Other compatibility issues
4113 - %union directives can now have a tag before the "{", e.g., the
4114 directive "%union foo {...}" now generates the C code
4115 "typedef union foo { ... } YYSTYPE;"; this is for Yacc compatibility.
4116 The default union tag is "YYSTYPE", for compatibility with Solaris 9 Yacc.
4117 For consistency, YYLTYPE's struct tag is now "YYLTYPE" not "yyltype".
4118 This is for compatibility with both Yacc and Bison 1.35.
4120 - ";" is output before the terminating "}" of an action, for
4121 compatibility with Bison 1.35.
4123 - Bison now uses a Yacc-style format for conflict reports, e.g.,
4124 "conflicts: 2 shift/reduce, 1 reduce/reduce".
4126 - "yystype" and "yyltype" are now obsolescent macros instead of being
4127 typedefs or tags; they are no longer documented and are planned to be
4128 withdrawn in a future release.
4133 Users of Bison have to decide how they handle the portability of the
4136 - "parsing stack overflow..." -> "parser stack overflow"
4137 GLR parsers now report "parser stack overflow" as per the Bison manual.
4139 ** %parse-param and %lex-param
4140 The macros YYPARSE_PARAM and YYLEX_PARAM provide a means to pass
4141 additional context to yyparse and yylex. They suffer from several
4144 - a single argument only can be added,
4145 - their types are weak (void *),
4146 - this context is not passed to ancillary functions such as yyerror,
4147 - only yacc.c parsers support them.
4149 The new %parse-param/%lex-param directives provide a more precise control.
4152 %parse-param {int *nastiness}
4153 %lex-param {int *nastiness}
4154 %parse-param {int *randomness}
4156 results in the following signatures:
4158 int yylex (int *nastiness);
4159 int yyparse (int *nastiness, int *randomness);
4161 or, if both %pure-parser and %locations are used:
4163 int yylex (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
4164 int yyparse (int *nastiness, int *randomness);
4166 ** Bison now warns if it detects conflicting outputs to the same file,
4167 e.g., it generates a warning for "bison -d -o foo.h foo.y" since
4168 that command outputs both code and header to foo.h.
4170 ** #line in output files
4171 - --no-line works properly.
4173 ** Bison can no longer be built by a K&R C compiler; it requires C89 or
4174 later to be built. This change originally took place a few versions
4175 ago, but nobody noticed until we recently asked someone to try
4176 building Bison with a K&R C compiler.
4179 * Noteworthy changes in release 1.75 (2002-10-14)
4181 ** Bison should now work on 64-bit hosts.
4183 ** Indonesian translation thanks to Tedi Heriyanto.
4186 Fix spurious parse errors.
4189 Some people redefine yyerror to steal yyparse' private variables.
4190 Reenable this trick until an official feature replaces it.
4193 In agreement with POSIX and with other Yaccs, leaving a default
4194 action is valid when $$ is untyped, and $1 typed:
4198 but the converse remains an error:
4202 ** Values of midrule actions
4205 foo: { ... } { $$ = $1; } ...
4207 was incorrectly rejected: $1 is defined in the second midrule
4208 action, and is equal to the $$ of the first midrule action.
4211 * Noteworthy changes in release 1.50 (2002-10-04)
4216 causes Bison to produce a Generalized LR (GLR) parser, capable of handling
4217 almost any context-free grammar, ambiguous or not. The new declarations
4218 %dprec and %merge on grammar rules allow parse-time resolution of
4219 ambiguities. Contributed by Paul Hilfinger.
4221 Unfortunately Bison 1.50 does not work properly on 64-bit hosts
4222 like the Alpha, so please stick to 32-bit hosts for now.
4225 When not in Yacc compatibility mode, when the output file was not
4226 specified, running "bison foo/bar.y" created "foo/bar.c". It
4227 now creates "bar.c".
4230 The undefined token was systematically mapped to 2 which prevented
4231 the use of 2 by the user. This is no longer the case.
4233 ** Unknown token numbers
4234 If yylex returned an out of range value, yyparse could die. This is
4238 According to POSIX, the error token must be 256.
4239 Bison extends this requirement by making it a preference: *if* the
4240 user specified that one of her tokens is numbered 256, then error
4241 will be mapped onto another number.
4243 ** Verbose error messages
4244 They no longer report "..., expecting error or..." for states where
4245 error recovery is possible.
4248 Defaults to "$end" instead of "$".
4250 ** Error recovery now conforms to documentation and to POSIX
4251 When a Bison-generated parser encounters a syntax error, it now pops
4252 the stack until it finds a state that allows shifting the error
4253 token. Formerly, it popped the stack until it found a state that
4254 allowed some non-error action other than a default reduction on the
4255 error token. The new behavior has long been the documented behavior,
4256 and has long been required by POSIX. For more details, please see
4257 Paul Eggert, "Reductions during Bison error handling" (2002-05-20)
4258 <https://lists.gnu.org/r/bug-bison/2002-05/msg00038.html>.
4261 Popped tokens and nonterminals are now reported.
4264 Larger grammars are now supported (larger token numbers, larger grammar
4265 size (= sum of the LHS and RHS lengths), larger LALR tables).
4266 Formerly, many of these numbers ran afoul of 16-bit limits;
4267 now these limits are 32 bits on most hosts.
4269 ** Explicit initial rule
4270 Bison used to play hacks with the initial rule, which the user does
4271 not write. It is now explicit, and visible in the reports and
4275 Before, Bison reported the useless rules, but, although not used,
4276 included them in the parsers. They are now actually removed.
4278 ** Useless rules, useless nonterminals
4279 They are now reported, as a warning, with their locations.
4281 ** Rules never reduced
4282 Rules that can never be reduced because of conflicts are now
4285 ** Incorrect "Token not used"
4286 On a grammar such as
4288 %token useless useful
4290 exp: '0' %prec useful;
4292 where a token was used to set the precedence of the last rule,
4293 bison reported both "useful" and "useless" as useless tokens.
4295 ** Revert the C++ namespace changes introduced in 1.31
4296 as they caused too many portability hassles.
4298 ** Default locations
4299 By an accident of design, the default computation of @$ was
4300 performed after another default computation was performed: @$ = @1.
4301 The latter is now removed: YYLLOC_DEFAULT is fully responsible of
4302 the computation of @$.
4304 ** Token end-of-file
4305 The token end of file may be specified by the user, in which case,
4306 the user symbol is used in the reports, the graphs, and the verbose
4307 error messages instead of "$end", which remains being the default.
4311 %token MYEOF 0 "end of file"
4314 This old option, which has been broken for ages, is removed.
4317 Brazilian Portuguese, thanks to Alexandre Folle de Menezes.
4318 Croatian, thanks to Denis Lackovic.
4320 ** Incorrect token definitions
4323 bison used to output
4326 ** Token definitions as enums
4327 Tokens are output both as the traditional #define's, and, provided
4328 the compiler supports ANSI C or is a C++ compiler, as enums.
4329 This lets debuggers display names instead of integers.
4332 In addition to --verbose, bison supports --report=THINGS, which
4333 produces additional information:
4335 complete the core item sets with their closure
4336 - lookahead [changed to "look-ahead" in 1.875e through 2.3, but changed back]
4337 explicitly associate lookahead tokens to items
4339 describe shift/reduce conflicts solving.
4340 Bison used to systematically output this information on top of
4341 the report. Solved conflicts are now attached to their states.
4344 Previous versions don't complain when there is a type clash on
4345 the default action if the rule has a midrule action, such as in:
4353 ** GNU M4 is now required when using Bison.
4356 * Noteworthy changes in release 1.35 (2002-03-25)
4359 Some projects use Bison's C parser with C++ compilers, and define
4360 YYSTYPE as a class. The recent adjustment of C parsers for data
4361 alignment and 64 bit architectures made this impossible.
4363 Because for the time being no real solution for C++ parser
4364 generation exists, kludges were implemented in the parser to
4365 maintain this use. In the future, when Bison has C++ parsers, this
4366 kludge will be disabled.
4368 This kludge also addresses some C++ problems when the stack was
4372 * Noteworthy changes in release 1.34 (2002-03-12)
4374 ** File name clashes are detected
4375 $ bison foo.y -d -o foo.x
4376 fatal error: header and parser would both be named "foo.x"
4378 ** A missing ";" at the end of a rule triggers a warning
4379 In accordance with POSIX, and in agreement with other
4380 Yacc implementations, Bison will mandate this semicolon in the near
4381 future. This eases the implementation of a Bison parser of Bison
4382 grammars by making this grammar LALR(1) instead of LR(2). To
4383 facilitate the transition, this release introduces a warning.
4385 ** Revert the C++ namespace changes introduced in 1.31, as they caused too
4386 many portability hassles.
4388 ** DJGPP support added.
4390 ** Fix test suite portability problems.
4393 * Noteworthy changes in release 1.33 (2002-02-07)
4396 Groff could not be compiled for the definition of size_t was lacking
4397 under some conditions.
4403 * Noteworthy changes in release 1.32 (2002-01-23)
4405 ** Fix Yacc output file names
4407 ** Portability fixes
4409 ** Italian, Dutch translations
4412 * Noteworthy changes in release 1.31 (2002-01-14)
4416 ** GNU Gettext and %expect
4417 GNU Gettext asserts 10 s/r conflicts, but there are 7. Now that
4418 Bison dies on incorrect %expectations, we fear there will be
4419 too many bug reports for Gettext, so _for the time being_, %expect
4420 does not trigger an error when the input file is named "plural.y".
4422 ** Use of alloca in parsers
4423 If YYSTACK_USE_ALLOCA is defined to 0, then the parsers will use
4424 malloc exclusively. Since 1.29, but was not NEWS'ed.
4426 alloca is used only when compiled with GCC, to avoid portability
4429 ** yyparse now returns 2 if memory is exhausted; formerly it dumped core.
4431 ** When the generated parser lacks debugging code, YYDEBUG is now 0
4432 (as POSIX requires) instead of being undefined.
4435 Bison has always permitted actions such as { $$ = $1 }: it adds the
4436 ending semicolon. Now if in Yacc compatibility mode, the semicolon
4437 is no longer output: one has to write { $$ = $1; }.
4439 ** Better C++ compliance
4440 The output parsers try to respect C++ namespaces.
4441 [This turned out to be a failed experiment, and it was reverted later.]
4444 Fixed bugs when reporting useless nonterminals.
4447 The parsers work properly on 64 bit hosts.
4450 Some calls to strerror resulted in scrambled or missing error messages.
4453 When the number of shift/reduce conflicts is correct, don't issue
4456 ** The verbose report includes the rule line numbers.
4458 ** Rule line numbers are fixed in traces.
4460 ** Swedish translation
4463 Verbose parse error messages from the parsers are better looking.
4464 Before: parse error: unexpected `'/'', expecting `"number"' or `'-'' or `'(''
4465 Now: parse error: unexpected '/', expecting "number" or '-' or '('
4467 ** Fixed parser memory leaks.
4468 When the generated parser was using malloc to extend its stacks, the
4469 previous allocations were not freed.
4471 ** Fixed verbose output file.
4472 Some newlines were missing.
4473 Some conflicts in state descriptions were missing.
4475 ** Fixed conflict report.
4476 Option -v was needed to get the result.
4480 Mismatches are errors, not warnings.
4482 ** Fixed incorrect processing of some invalid input.
4484 ** Fixed CPP guards: 9foo.h uses BISON_9FOO_H instead of 9FOO_H.
4486 ** Fixed some typos in the documentation.
4488 ** %token MY_EOF 0 is supported.
4489 Before, MY_EOF was silently renumbered as 257.
4491 ** doc/refcard.tex is updated.
4493 ** %output, %file-prefix, %name-prefix.
4497 New, aliasing "--output-file".
4500 * Noteworthy changes in release 1.30 (2001-10-26)
4502 ** "--defines" and "--graph" have now an optional argument which is the
4503 output file name. "-d" and "-g" do not change; they do not take any
4506 ** "%source_extension" and "%header_extension" are removed, failed
4509 ** Portability fixes.
4512 * Noteworthy changes in release 1.29 (2001-09-07)
4514 ** The output file does not define const, as this caused problems when used
4515 with common autoconfiguration schemes. If you still use ancient compilers
4516 that lack const, compile with the equivalent of the C compiler option
4517 "-Dconst=". Autoconf's AC_C_CONST macro provides one way to do this.
4519 ** Added "-g" and "--graph".
4521 ** The Bison manual is now distributed under the terms of the GNU FDL.
4523 ** The input and the output files has automatically a similar extension.
4525 ** Russian translation added.
4527 ** NLS support updated; should hopefully be less troublesome.
4529 ** Added the old Bison reference card.
4531 ** Added "--locations" and "%locations".
4533 ** Added "-S" and "--skeleton".
4535 ** "%raw", "-r", "--raw" is disabled.
4537 ** Special characters are escaped when output. This solves the problems
4538 of the #line lines with path names including backslashes.
4541 "%yacc", "%fixed_output_files", "%defines", "%no_parser", "%verbose",
4542 "%debug", "%source_extension" and "%header_extension".
4545 Automatic location tracking.
4548 * Noteworthy changes in release 1.28 (1999-07-06)
4550 ** Should compile better now with K&R compilers.
4554 ** Fixed a problem with escaping the double quote character.
4556 ** There is now a FAQ.
4559 * Noteworthy changes in release 1.27
4561 ** The make rule which prevented bison.simple from being created on
4562 some systems has been fixed.
4565 * Noteworthy changes in release 1.26
4567 ** Bison now uses Automake.
4569 ** New mailing lists: <bug-bison@gnu.org> and <help-bison@gnu.org>.
4571 ** Token numbers now start at 257 as previously documented, not 258.
4573 ** Bison honors the TMPDIR environment variable.
4575 ** A couple of buffer overruns have been fixed.
4577 ** Problems when closing files should now be reported.
4579 ** Generated parsers should now work even on operating systems which do
4580 not provide alloca().
4583 * Noteworthy changes in release 1.25 (1995-10-16)
4585 ** Errors in the input grammar are not fatal; Bison keeps reading
4586 the grammar file, and reports all the errors found in it.
4588 ** Tokens can now be specified as multiple-character strings: for
4589 example, you could use "<=" for a token which looks like <=, instead
4590 of choosing a name like LESSEQ.
4592 ** The %token_table declaration says to write a table of tokens (names
4593 and numbers) into the parser file. The yylex function can use this
4594 table to recognize multiple-character string tokens, or for other
4597 ** The %no_lines declaration says not to generate any #line preprocessor
4598 directives in the parser file.
4600 ** The %raw declaration says to use internal Bison token numbers, not
4601 Yacc-compatible token numbers, when token names are defined as macros.
4603 ** The --no-parser option produces the parser tables without including
4604 the parser engine; a project can now use its own parser engine.
4605 The actions go into a separate file called NAME.act, in the form of
4606 a switch statement body.
4609 * Noteworthy changes in release 1.23
4611 The user can define YYPARSE_PARAM as the name of an argument to be
4612 passed into yyparse. The argument should have type void *. It should
4613 actually point to an object. Grammar actions can access the variable
4614 by casting it to the proper pointer type.
4616 Line numbers in output file corrected.
4619 * Noteworthy changes in release 1.22
4621 --help option added.
4624 * Noteworthy changes in release 1.20
4626 Output file does not redefine const for C++.
4630 LocalWords: yacc YYBACKUP glr GCC lalr ArrayIndexOutOfBoundsException nullptr
4631 LocalWords: cplusplus liby rpl fprintf mfcalc Wyacc stmt cond expr mk sym lr
4632 LocalWords: IELR ielr Lookahead YYERROR nonassoc LALR's api lookaheads yychar
4633 LocalWords: destructor lookahead YYRHSLOC YYLLOC Rhs ifndef YYFAIL cpp sr rr
4634 LocalWords: preprocessor initializer Wno Wnone Werror FreeBSD prec livelocks
4635 LocalWords: Solaris AIX UX RHEL Tru LHS gcc's Wundef YYENABLE NLS YYLTYPE VCG
4636 LocalWords: yyerror cpp's Wunused yylval yylloc prepend yyparse yylex yypush
4637 LocalWords: Graphviz xml nonterminals midrule destructor's YYSTYPE typedef ly
4638 LocalWords: CHR chr printf stdout namespace preprocessing enum pre include's
4639 LocalWords: YYRECOVERING nonfree destructors YYABORT YYACCEPT params enums de
4640 LocalWords: struct yystype DJGPP lex param Haible NUM alloca YYSTACK NUL goto
4641 LocalWords: YYMAXDEPTH Unescaped UCNs YYLTYPE's yyltype typedefs inline Yaccs
4642 LocalWords: Heriyanto Reenable dprec Hilfinger Eggert MYEOF Folle Menezes EOF
4643 LocalWords: Lackovic define's itemset Groff Gettext malloc NEWS'ed YYDEBUG YY
4644 LocalWords: namespaces strerror const autoconfiguration Dconst Autoconf's FDL
4645 LocalWords: Automake TMPDIR LESSEQ ylwrap endif yydebug YYTOKEN YYLSP ival hh
4646 LocalWords: extern YYTOKENTYPE TOKENTYPE yytokentype tokentype STYPE lval pdf
4647 LocalWords: lang yyoutput dvi html ps POSIX lvalp llocp Wother nterm arg init
4648 LocalWords: TOK calc yyo fval Wconflicts parsers yystackp yyval yynerrs
4649 LocalWords: Théophile Ranquet Santet fno fnone stype associativity Tolmer
4650 LocalWords: Wprecedence Rassoul Wempty Paolo Bonzini parser's Michiel loc
4651 LocalWords: redeclaration sval fcaret reentrant XSLT xsl Wmaybe yyvsp Tedi
4652 LocalWords: pragmas noreturn untyped Rozenman unexpanded Wojciech Polak
4653 LocalWords: Alexandre MERCHANTABILITY yytype emplace ptr automove lvalues
4654 LocalWords: nonterminal yy args Pragma dereference yyformat rhs docdir bw
4655 LocalWords: Redeclarations rpcalc Autoconf YFLAGS Makefiles PROG DECL num
4656 LocalWords: Heimbigner AST src ast Makefile srcdir MinGW xxlex XXSTYPE
4657 LocalWords: XXLTYPE strictfp IDEs ffixit fdiagnostics parseable fixits
4658 LocalWords: Wdeprecated yytext Variadic variadic yyrhs yyphrs RCS README
4659 LocalWords: noexcept constexpr ispell american deprecations backend Teoh
4660 LocalWords: YYPRINT Mangold Bonzini's Wdangling exVal baz checkable gcc
4661 LocalWords: fsanitize Vogelsgesang lis redeclared stdint automata yytname
4662 LocalWords: yysymbol yytnamerr yyreport ctx ARGMAX yysyntax stderr LPAREN
4663 LocalWords: symrec yypcontext TOKENMAX yyexpected YYEMPTY yypstate YYEOF
4664 LocalWords: autocompletion bistromathic submessages Cayuela lexcalc hoc
4665 LocalWords: yytoken YYUNDEF YYerror basename Automake's UTF ifdef ffile
4666 LocalWords: gotos readline Imbimbo Wcounterexamples Wcex Nonunifying rcex
4669 ispell-dictionary: "american"
4674 Copyright (C) 1995-2015, 2018-2021 Free Software Foundation, Inc.
4676 This file is part of Bison, the GNU Parser Generator.
4678 Permission is granted to copy, distribute and/or modify this document
4679 under the terms of the GNU Free Documentation License, Version 1.3 or
4680 any later version published by the Free Software Foundation; with no
4681 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
4682 Texts. A copy of the license is included in the "GNU Free
4683 Documentation License" file as part of this distribution.