3 * Noteworthy changes in release ?.? (????-??-??) [?]
9 *** Option -H, --header
11 The option -H/--header replaces the option --defines (maintained for
12 backward compatibility).
14 *** A C++ native GLR parser
16 A new version of the generated C++ GLR parser was added as "glr2.cc". It
17 is forked from the existing glr.c/cc parser, with the objective of making
18 it a more modern, truly C++ parser (instead of a C++ wrapper around a C
19 parser). Down the line, the goal is to support `%define api.value.type
20 variant` and maybe share code with lalr1.cc.
22 The current parser should be identical in terms of interface, functionality
23 and performance to "glr.cc". To try it out, simply use
29 Counterexamples now show the rule numbers, and always show ε for rules
30 with an empty right-hand side. For instance
43 * Noteworthy changes in release 3.7.2 (2020-09-05) [stable]
45 This release of Bison fixes all known bugs reported for Bison in MITRE's
46 Common Vulnerabilities and Exposures (CVE) system. These vulnerabilities
47 are only about bison-the-program itself, not the generated code.
49 Although these bugs are typically irrelevant to how Bison is used, they
50 are worth fixing if only to give users peace of mind.
52 There is no known vulnerability in the generated parsers.
56 Fix concurrent build issues (introduced in Bison 3.5).
58 Push parsers always use YYMALLOC/YYFREE (no direct calls to malloc/free).
60 Fix portability issues of the test suite, and of bison itself.
62 Some unlikely crashes found by fuzzing have been fixed. This is only
63 about bison itself, not the generated parsers.
66 * Noteworthy changes in release 3.7.1 (2020-08-02) [stable]
70 Crash when a token alias contains a NUL byte.
72 Portability issues with libtextstyle.
74 Portability issues of Bison itself with MSVC.
78 Improvements and fixes in the documentation.
80 More precise location about symbol type redefinitions.
83 * Noteworthy changes in release 3.7 (2020-07-23) [stable]
85 ** Deprecated features
87 The YYPRINT macro, which works only with yacc.c and only for tokens, was
88 obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
89 It is deprecated and its support will be removed eventually.
91 In conformance with the recommendations of the Graphviz team, in the next
92 version Bison the option `--graph` will generate a *.gv file by default,
93 instead of *.dot. A transition started in Bison 3.4.
97 *** Counterexample Generation
99 Contributed by Vincent Imbimbo.
101 When given `-Wcounterexamples`/`-Wcex`, bison will now output
102 counterexamples for conflicts.
104 **** Unifying Counterexamples
106 Unifying counterexamples are strings which can be parsed in two ways due
107 to the conflict. For example on a grammar that contains the usual
108 "dangling else" ambiguity:
111 else.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
112 else.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
115 else.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
116 else.y: warning: shift/reduce conflict on token "else" [-Wcounterexamples]
117 Example: "if" exp "then" "if" exp "then" exp • "else" exp
120 ↳ "if" exp "then" exp
121 ↳ "if" exp "then" exp • "else" exp
122 Example: "if" exp "then" "if" exp "then" exp • "else" exp
125 ↳ "if" exp "then" exp "else" exp
126 ↳ "if" exp "then" exp •
128 When text styling is enabled, colors are used in the examples and the
129 derivations to highlight the structure of both analyses. In this case,
131 "if" exp "then" [ "if" exp "then" exp • ] "else" exp
135 "if" exp "then" [ "if" exp "then" exp • "else" exp ]
138 The counterexamples are "focused", in two different ways. First, they do
139 not clutter the output with all the derivations from the start symbol,
140 rather they start on the "conflicted nonterminal". They go straight to the
141 point. Second, they don't "expand" nonterminal symbols uselessly.
143 **** Nonunifying Counterexamples
145 In the case of the dangling else, Bison found an example that can be
146 parsed in two ways (therefore proving that the grammar is ambiguous).
147 When it cannot find such an example, it instead generates two examples
148 that are the same up until the dot:
151 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
152 foo.y: note: rerun with option '-Wcounterexamples' to generate conflict counterexamples
153 foo.y:4.4-7: warning: rule useless in parser due to conflicts [-Wother]
158 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
159 foo.y: warning: shift/reduce conflict on token ID [-Wcounterexamples]
160 First example: expr • ID ',' ID $end
167 Second example: expr • ID $end
173 foo.y:4.4-7: warning: rule useless in parser due to conflicts [-Wother]
177 In these cases, the parser usually doesn't have enough lookahead to
178 differentiate the two given examples.
182 Counterexamples are also included in the report when given
183 `--report=counterexamples`/`-rcex` (or `--report=all`), with more
188 1 exp: "if" exp "then" exp • [$end, "then", "else"]
189 2 | "if" exp "then" exp • "else" exp
191 "else" shift, and go to state 8
193 "else" [reduce using rule 1 (exp)]
194 $default reduce using rule 1 (exp)
196 shift/reduce conflict on token "else":
197 1 exp: "if" exp "then" exp •
198 2 exp: "if" exp "then" exp • "else" exp
199 Example: "if" exp "then" "if" exp "then" exp • "else" exp
202 ↳ "if" exp "then" exp
203 ↳ "if" exp "then" exp • "else" exp
204 Example: "if" exp "then" "if" exp "then" exp • "else" exp
207 ↳ "if" exp "then" exp "else" exp
208 ↳ "if" exp "then" exp •
210 *** File prefix mapping
212 Contributed by Joshua Watt.
214 Bison learned a new argument, `--file-prefix-map OLD=NEW`. Any file path
215 in the output (specifically `#line` directives and `#ifdef` header guards)
216 that begins with the prefix OLD will have it replaced with the prefix NEW,
217 similar to the `-ffile-prefix-map` in GCC. This option can be used to
218 make bison output reproducible.
224 When text styling is enabled and the terminal supports it, the warnings
225 now include hyperlinks to the documentation.
227 *** Relocatable installation
229 When installed to be relocatable (via `configure --enable-relocatable`),
230 bison will now also look for a relocated m4.
234 The `filename_type` %define variable was renamed `api.filename.type`.
237 %define filename_type "symbol"
241 %define api.filename.type {symbol}
243 (Or let `bison --update` do it for you).
245 It now defaults to `const std::string` instead of `std::string`.
247 *** Deprecated %define variable names
249 The following variables have been renamed for consistency. Backward
250 compatibility is ensured, but upgrading is recommended.
252 filename_type -> api.filename.type
253 package -> api.package
255 *** Push parsers no longer clear their state when parsing is finished
257 Previously push-parsers cleared their state when parsing was finished (on
258 success and on failure). This made it impossible to check if there were
259 parse errors, since `yynerrs` was also reset. This can be especially
260 troublesome when used in autocompletion, since a parser with error
261 recovery would suggest (irrelevant) expected tokens even if there were
264 Now the parser state can be examined when parsing is finished. The parser
265 state is reset when starting a new parse.
271 The bistromathic demonstrates %param and how to quote sources in the error
275 1.5-7: syntax error: expected end of file or + or - or * or / or ^ before number
281 *** Include the generated header (yacc.c)
283 Historically, when --defines was used, bison generated a header and pasted
284 an exact copy of it into the generated parser implementation file. Since
285 Bison 3.4 it is possible to specify that the header should be `#include`d,
286 and how. For instance
288 %define api.header.include {"parse.h"}
292 %define api.header.include {<parser/parse.h>}
294 Now api.header.include defaults to `"header-basename"`, as was intended in
295 Bison 3.4, where `header-basename` is the basename of the generated
296 header. This is disabled when the generated header is `y.tab.h`, to
297 comply with Automake's ylwrap.
299 *** String aliases are faithfully propagated
301 Bison used to interpret user strings (i.e., decoding backslash escapes)
302 when reading them, and to escape them (i.e., issue non-printable
303 characters as backslash escapes, taking the locale into account) when
304 outputting them. As a consequence non-ASCII strings (say in UTF-8) ended
305 up "ciphered" as sequences of backslash escapes. This happened not only
306 in the generated sources (where the compiler will reinterpret them), but
307 also in all the generated reports (text, xml, html, dot, etc.). Reports
308 were therefore not readable when string aliases were not pure ASCII.
309 Worse yet: the output depended on the user's locale.
311 Now Bison faithfully treats the string aliases exactly the way the user
312 spelled them. This fixes all the aforementioned problems. However, now,
313 string aliases semantically equivalent but syntactically different (e.g.,
314 "A", "\x41", "\101") are considered to be different.
316 *** Crash when generating IELR
318 An old, well hidden, bug in the generation of IELR parsers was fixed.
321 * Noteworthy changes in release 3.6.4 (2020-06-15) [stable]
325 In glr.cc some internal macros leaked in the user's code, and could damage
326 access to the token kinds.
329 * Noteworthy changes in release 3.6.3 (2020-06-03) [stable]
333 Incorrect comments in the generated parsers.
335 Warnings in push parsers (yacc.c).
337 Incorrect display of gotos in LAC traces (lalr1.cc).
340 * Noteworthy changes in release 3.6.2 (2020-05-17) [stable]
344 Some tests were fixed.
346 When token aliases contain comment delimiters:
348 %token FOO "/* foo */"
350 bison used to emit "nested" comments, which is invalid C.
353 * Noteworthy changes in release 3.6.1 (2020-05-10) [stable]
357 Restored ANSI-C compliance in yacc.c.
359 GNU readline portability issues.
361 In C++, yy::parser::symbol_name is now a public member, as was intended.
365 In C++, yy::parser::symbol_type now has a public name() member function.
368 * Noteworthy changes in release 3.6 (2020-05-08) [stable]
370 ** Backward incompatible changes
372 TL;DR: replace "#define YYERROR_VERBOSE 1" by "%define parse.error verbose".
374 The YYERROR_VERBOSE macro is no longer supported; the parsers that still
375 depend on it will now produce Yacc-like error messages (just "syntax
376 error"). It was superseded by the "%error-verbose" directive in Bison
377 1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that support
378 for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
379 (2013-07-25), "%error-verbose" is deprecated in favor of "%define
380 parse.error verbose".
382 ** Deprecated features
384 The YYPRINT macro, which works only with yacc.c and only for tokens, was
385 obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
386 It is deprecated and its support will be removed eventually.
390 *** Improved syntax error messages
392 Two new values for the %define parse.error variable offer more control to
393 the user. Available in all the skeletons (C, C++, Java).
395 **** %define parse.error detailed
397 The behavior of "%define parse.error detailed" is closely resembling that
398 of "%define parse.error verbose" with a few exceptions. First, it is safe
399 to use non-ASCII characters in token aliases (with 'verbose', the result
400 depends on the locale with which bison was run). Second, a yysymbol_name
401 function is exposed to the user, instead of the yytnamerr function and the
402 yytname table. Third, token internationalization is supported (see
405 **** %define parse.error custom
407 With this directive, the user forges and emits the syntax error message
408 herself by defining the yyreport_syntax_error function. A new type,
409 yypcontext_t, captures the circumstances of the error, and provides the
410 user with functions to get details, such as yypcontext_expected_tokens to
411 get the list of expected token kinds.
413 A possible implementation of yyreport_syntax_error is:
416 yyreport_syntax_error (const yypcontext_t *ctx)
419 YY_LOCATION_PRINT (stderr, *yypcontext_location (ctx));
420 fprintf (stderr, ": syntax error");
421 // Report the tokens expected at this point.
423 enum { TOKENMAX = 10 };
424 yysymbol_kind_t expected[TOKENMAX];
425 int n = yypcontext_expected_tokens (ctx, expected, TOKENMAX);
427 // Forward errors to yyparse.
430 for (int i = 0; i < n; ++i)
431 fprintf (stderr, "%s %s",
432 i == 0 ? ": expected" : " or", yysymbol_name (expected[i]));
434 // Report the unexpected token.
436 yysymbol_kind_t lookahead = yypcontext_token (ctx);
437 if (lookahead != YYSYMBOL_YYEMPTY)
438 fprintf (stderr, " before %s", yysymbol_name (lookahead));
440 fprintf (stderr, "\n");
444 **** Token aliases internationalization
446 When the %define variable parse.error is set to `custom` or `detailed`,
447 one may specify which token aliases are to be translated using _(). For
459 In that case the user must define _() and N_(), and yysymbol_name returns
460 the translated symbol (i.e., it returns '_("variable")' rather that
461 '"variable"'). In Java, the user must provide an i18n() function.
463 *** List of expected tokens (yacc.c)
465 Push parsers may invoke yypstate_expected_tokens at any point during
466 parsing (including even before submitting the first token) to get the list
467 of possible tokens. This feature can be used to propose autocompletion
468 (see below the "bistromathic" example).
470 It makes little sense to use this feature without enabling LAC (lookahead
473 *** Returning the error token
475 When the scanner returns an invalid token or the undefined token
476 (YYUNDEF), the parser generates an error message and enters error
477 recovery. Because of that error message, most scanners that find lexical
478 errors generate an error message, and then ignore the invalid input
479 without entering the error-recovery.
481 The scanners may now return YYerror, the error token, to enter the
482 error-recovery mode without triggering an additional error message. See
483 the bistromathic for an example.
485 *** Deep overhaul of the symbol and token kinds
487 To avoid the confusion with types in programming languages, we now refer
488 to token and symbol "kinds" instead of token and symbol "types". The
489 documentation and error messages have been revised.
491 All the skeletons have been updated to use dedicated enum types rather
492 than integral types. Special symbols are now regular citizens, instead of
493 being declared in ad hoc ways.
497 The "token kind" is what is returned by the scanner, e.g., PLUS, NUMBER,
498 LPAREN, etc. While backward compatibility is of course ensured, users are
499 nonetheless invited to replace their uses of "enum yytokentype" by
502 This type now also includes tokens that were previously hidden: YYEOF (end
503 of input), YYUNDEF (undefined token), and YYerror (error token). They
504 now have string aliases, internationalized when internationalization is
505 enabled. Therefore, by default, error messages now refer to "end of file"
506 (internationalized) rather than the cryptic "$end", or to "invalid token"
507 rather than "$undefined".
509 Therefore in most cases it is now useless to define the end-of-line token
512 %token T_EOF 0 "end of file"
514 Rather simply use "YYEOF" in your scanner.
518 The "symbol kinds" is what the parser actually uses. (Unless the
519 api.token.raw %define variable is used, the symbol kind of a terminal
520 differs from the corresponding token kind.)
522 They are now exposed as a enum, "yysymbol_kind_t".
524 This allows users to tailor the error messages the way they want, or to
525 process some symbols in a specific way in autocompletion (see the
526 bistromathic example below).
528 *** Modernize display of explanatory statements in diagnostics
530 Since Bison 2.7, output was indented four spaces for explanatory
531 statements. For example:
533 input.y:2.7-13: error: %type redeclaration for exp
534 input.y:1.7-11: previous declaration
536 Since the introduction of caret-diagnostics, it became less clear. This
537 indentation has been removed and submessages are displayed similarly as in
540 input.y:2.7-13: error: %type redeclaration for exp
541 2 | %type <float> exp
543 input.y:1.7-11: note: previous declaration
547 Contributed by Victor Morales Cayuela.
551 The token and symbol kinds are yy::parser::token_kind_type and
552 yy::parser::symbol_kind_type.
554 The symbol_type::kind() member function allows to get the kind of a
555 symbol. This can be used to write unit tests for scanners, e.g.,
557 yy::parser::symbol_type t = make_NUMBER ("123");
558 assert (t.kind () == yy::parser::symbol_kind::S_NUMBER);
559 assert (t.value.as<int> () == 123);
565 In order to avoid ambiguities with "type" as in "typing", we now refer to
566 the "token kind" (e.g., `PLUS`, `NUMBER`, etc.) rather than the "token
567 type". We now also refer to the "symbol type" (e.g., `PLUS`, `expr`,
572 There are now examples/java: a very simple calculator, and a more complete
573 one (push-parser, location tracking, and debug traces).
575 The lexcalc example (a simple example in C based on Flex and Bison) now
576 also demonstrates location tracking.
579 A new C example, bistromathic, is a fully featured interactive calculator
580 using many Bison features: pure interface, push parser, autocompletion
581 based on the current parser state (using yypstate_expected_tokens),
582 location tracking, internationalized custom error messages, lookahead
583 correction, rich debug traces, etc.
585 It shows how to depend on the symbol kinds to tailor autocompletion. For
586 instance it recognizes the symbol kind "VARIABLE" to propose
587 autocompletion on the existing variables, rather than of the word
591 * Noteworthy changes in release 3.5.4 (2020-04-05) [stable]
593 ** WARNING: Future backward-incompatibilities!
595 TL;DR: replace "#define YYERROR_VERBOSE 1" by "%define parse.error verbose".
597 Bison 3.6 will no longer support the YYERROR_VERBOSE macro; the parsers
598 that still depend on it will produce Yacc-like error messages (just
599 "syntax error"). It was superseded by the "%error-verbose" directive in
600 Bison 1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that
601 support for YYERROR_VERBOSE would be removed. Note that since Bison 3.0
602 (2013-07-25), "%error-verbose" is deprecated in favor of "%define
603 parse.error verbose".
607 Fix portability issues of the package itself on old compilers.
609 Fix api.token.raw support in Java.
612 * Noteworthy changes in release 3.5.3 (2020-03-08) [stable]
616 Error messages could quote lines containing zero-width characters (such as
617 \005) with incorrect styling. Fixes for similar issues with unexpectedly
618 short lines (e.g., the file was changed between parsing and diagnosing).
620 Some unlikely crashes found by fuzzing have been fixed. This is only
621 about bison itself, not the generated parsers.
624 * Noteworthy changes in release 3.5.2 (2020-02-13) [stable]
628 Portability issues and minor cosmetic issues.
630 The lalr1.cc skeleton properly rejects unsupported values for parse.lac
634 * Noteworthy changes in release 3.5.1 (2020-01-19) [stable]
640 Fix compiler warnings.
643 * Noteworthy changes in release 3.5 (2019-12-11) [stable]
645 ** Backward incompatible changes
647 Lone carriage-return characters (aka \r or ^M) in the grammar files are no
648 longer treated as end-of-lines. This changes the diagnostics, and in
649 particular their locations.
651 In C++, line numbers and columns are now represented as 'int' not
652 'unsigned', so that integer overflow on positions is easily checkable via
653 'gcc -fsanitize=undefined' and the like. This affects the API for
654 positions. The default position and location classes now expose
655 'counter_type' (int), used to define line and column numbers.
657 ** Deprecated features
659 The YYPRINT macro, which works only with yacc.c and only for tokens, was
660 obsoleted long ago by %printer, introduced in Bison 1.50 (November 2002).
661 It is deprecated and its support will be removed eventually.
665 *** Lookahead correction in C++
667 Contributed by Adrian Vogelsgesang.
669 The C++ deterministic skeleton (lalr1.cc) now supports LAC, via the
670 %define variable parse.lac.
672 *** Variable api.token.raw: Optimized token numbers (all skeletons)
674 In the generated parsers, tokens have two numbers: the "external" token
675 number as returned by yylex (which starts at 257), and the "internal"
676 symbol number (which starts at 3). Each time yylex is called, a table
677 lookup maps the external token number to the internal symbol number.
679 When the %define variable api.token.raw is set, tokens are assigned their
680 internal number, which saves one table lookup per token, and also saves
681 the generation of the mapping table.
683 The gain is typically moderate, but in extreme cases (very simple user
684 actions), a 10% improvement can be observed.
686 *** Generated parsers use better types for states
688 Stacks now use the best integral type for state numbers, instead of always
689 using 15 bits. As a result "small" parsers now have a smaller memory
690 footprint (they use 8 bits), and there is support for large automata (16
691 bits), and extra large (using int, i.e., typically 31 bits).
693 *** Generated parsers prefer signed integer types
695 Bison skeletons now prefer signed to unsigned integer types when either
696 will do, as the signed types are less error-prone and allow for better
697 checking with 'gcc -fsanitize=undefined'. Also, the types chosen are now
698 portable to unusual machines where char, short and int are all the same
699 width. On non-GNU platforms this may entail including <limits.h> and (if
700 available) <stdint.h> to define integer types and constants.
702 *** A skeleton for the D programming language
704 For the last few releases, Bison has shipped a stealth experimental
705 skeleton: lalr1.d. It was first contributed by Oliver Mangold, based on
706 Paolo Bonzini's lalr1.java, and was cleaned and improved thanks to
709 However, because nobody has committed to improving, testing, and
710 documenting this skeleton, it is not clear that it will be supported in
713 The lalr1.d skeleton *is functional*, and works well, as demonstrated in
714 examples/d/calc.d. Please try it, enjoy it, and... commit to support it.
716 *** Debug traces in Java
718 The Java backend no longer emits code and data for parser tracing if the
719 %define variable parse.trace is not defined.
723 *** New diagnostic: -Wdangling-alias
725 String literals, which allow for better error messages, are (too)
726 liberally accepted by Bison, which might result in silent errors. For
729 %type <exVal> cond "condition"
731 does not define "condition" as a string alias to 'cond' (nonterminal
732 symbols do not have string aliases). It is rather equivalent to
735 %token <exVal> "condition"
737 i.e., it gives the type 'exVal' to the "condition" token, which was
738 clearly not the intention.
740 Also, because string aliases need not be defined, typos such as "baz"
741 instead of "bar" will be not reported.
743 The option -Wdangling-alias catches these situations. On
746 %type <ival> foo "foo"
750 bison -Wdangling-alias reports
752 warning: string literal not attached to a symbol
753 | %type <ival> foo "foo"
755 warning: string literal not attached to a symbol
759 The -Wall option does not (yet?) include -Wdangling-alias.
761 *** Better POSIX Yacc compatibility diagnostics
763 POSIX Yacc restricts %type to nonterminals. This is now diagnosed by
767 %type <ival> TOKEN1 TOKEN2 't'
774 input.y:2.15-20: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
775 2 | %type <ival> TOKEN1 TOKEN2 't'
777 input.y:2.29-31: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
778 2 | %type <ival> TOKEN1 TOKEN2 't'
780 input.y:2.22-27: warning: POSIX yacc reserves %type to nonterminals [-Wyacc]
781 2 | %type <ival> TOKEN1 TOKEN2 't'
784 *** Diagnostics with insertion
786 The diagnostics now display the suggestion below the underlined source.
787 Replacement for undeclared symbols are now also suggested.
794 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'?
798 foo.y:2.16: warning: empty rule without %empty [-Wempty-rule]
802 foo.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
804 *** Diagnostics about long lines
806 Quoted sources may now be truncated to fit the screen. For instance, on a
807 30-column wide terminal:
814 foo.y:1.34-36: warning: symbol FOO redeclared [-Wother]
817 foo.y:1.8-10: previous declaration
820 foo.y:1.62-64: warning: symbol FOO redeclared [-Wother]
823 foo.y:1.8-10: previous declaration
829 *** Debugging glr.c and glr.cc
831 The glr.c skeleton always had asserts to check its own behavior (not the
832 user's). These assertions are now under the control of the parse.assert
833 %define variable (disabled by default).
837 Several new compiler warnings in the generated output have been avoided.
838 Some unused features are no longer emitted. Cleaner generated code in
843 Portability issues in the test suite.
845 In theory, parsers using %nonassoc could crash when reporting verbose
846 error messages. This unlikely bug has been fixed.
848 In Java, %define api.prefix was ignored. It now behaves as expected.
851 * Noteworthy changes in release 3.4.2 (2019-09-12) [stable]
855 In some cases, when warnings are disabled, bison could emit tons of white
856 spaces as diagnostics.
858 When running out of memory, bison could crash (found by fuzzing).
860 When defining twice the EOF token, bison would crash.
862 New warnings from recent compilers have been addressed in the generated
863 parsers (yacc.c, glr.c, glr.cc).
865 When lone carriage-return characters appeared in the input file,
866 diagnostics could hang forever.
869 * Noteworthy changes in release 3.4.1 (2019-05-22) [stable]
876 * Noteworthy changes in release 3.4 (2019-05-19) [stable]
878 ** Deprecated features
880 The %pure-parser directive is deprecated in favor of '%define api.pure'
881 since Bison 2.3b (2008-05-27), but no warning was issued; there is one
882 now. Note that since Bison 2.7 you are strongly encouraged to use
883 '%define api.pure full' instead of '%define api.pure'.
887 *** Colored diagnostics
889 As an experimental feature, diagnostics are now colored, controlled by the
890 new options --color and --style.
892 To use them, install the libtextstyle library before configuring Bison.
895 https://alpha.gnu.org/gnu/gettext/
899 https://alpha.gnu.org/gnu/gettext/libtextstyle-0.8.tar.gz
901 The option --color supports the following arguments:
902 - always, yes: Enable colors.
903 - never, no: Disable colors.
904 - auto, tty (default): Enable colors if the output device is a tty.
906 To customize the styles, create a CSS file similar to
910 .error { font-weight: 800; text-decoration: underline; }
913 then invoke bison with --style=bison-bw.css, or set the BISON_STYLE
914 environment variable to "bison-bw.css".
918 When given -fsyntax-only, the diagnostics are reported, but no output is
921 The name of this option is somewhat misleading as bison does more than
922 just checking the syntax: every stage is run (including checking for
923 conflicts for instance), except the generation of the output files.
925 *** Include the generated header (yacc.c)
927 Before, when --defines is used, bison generated a header, and pasted an
928 exact copy of it into the generated parser implementation file. If the
929 header name is not "y.tab.h", it is now #included instead of being
932 To use an '#include' even if the header name is "y.tab.h" (which is what
933 happens with --yacc, or when using the Autotools' ylwrap), define
934 api.header.include to the exact argument to pass to #include. For
937 %define api.header.include {"parse.h"}
941 %define api.header.include {<parser/parse.h>}
943 *** api.location.type is now supported in C (yacc.c, glr.c)
945 The %define variable api.location.type defines the name of the type to use
946 for locations. When defined, Bison no longer defines YYLTYPE.
948 This can be used in programs with several parsers to factor their
949 definition of locations: let one of them generate them, and the others
956 In conformance with the recommendations of the Graphviz team, if %require
957 "3.4" (or better) is specified, the option --graph generates a *.gv file
958 by default, instead of *.dot.
960 *** Diagnostics overhaul
962 Column numbers were wrong with multibyte characters, which would also
963 result in skewed diagnostics with carets. Beside, because we were
964 indenting the quoted source with a single space, lines with tab characters
965 were incorrectly underlined.
967 To address these issues, and to be clearer, Bison now issues diagnostics
968 as GCC9 does. For instance it used to display (there's a tab before the
971 foo.y:3.37-38: error: $2 of ‘expr’ has no declared type
972 expr: expr '+' "number" { $$ = $1 + $2; }
976 foo.y:3.37-38: error: $2 of ‘expr’ has no declared type
977 3 | expr: expr '+' "number" { $$ = $1 + $2; }
980 Other constructs now also have better locations, resulting in more precise
983 *** Fix-it hints for %empty
985 Running Bison with -Wempty-rules and --update will remove incorrect %empty
986 annotations, and add the missing ones.
988 *** Generated reports
990 The format of the reports (parse.output) was improved for readability.
992 *** Better support for --no-line.
994 When --no-line is used, the generated files are now cleaner: no lines are
995 generated instead of empty lines. Together with using api.header.include,
996 that should help people saving the generated files into version control
997 systems get smaller diffs.
1001 A new example in C shows an simple infix calculator with a hand-written
1002 scanner (examples/c/calc).
1004 A new example in C shows a reentrant parser (capable of recursive calls)
1005 built with Flex and Bison (examples/c/reccalc).
1007 There is a new section about the history of Yaccs and Bison.
1011 A few obscure bugs were fixed, including the second oldest (known) bug in
1012 Bison: it was there when Bison was entered in the RCS version control
1013 system, in December 1987. See the NEWS of Bison 3.3 for the previous
1017 * Noteworthy changes in release 3.3.2 (2019-02-03) [stable]
1021 Bison 3.3 failed to generate parsers for grammars with unused nonterminal
1025 * Noteworthy changes in release 3.3.1 (2019-01-27) [stable]
1029 The option -y/--yacc used to imply -Werror=yacc, which turns uses of Bison
1030 extensions into errors. It now makes them simple warnings (-Wyacc).
1033 * Noteworthy changes in release 3.3 (2019-01-26) [stable]
1035 A new mailing list was created, Bison Announce. It is low traffic, and is
1036 only about announcing new releases and important messages (e.g., polls
1037 about major decisions to make).
1039 https://lists.gnu.org/mailman/listinfo/bison-announce
1041 ** Backward incompatible changes
1043 Support for DJGPP, which has been unmaintained and untested for years, is
1046 ** Deprecated features
1048 A new feature, --update (see below) helps adjusting existing grammars to
1051 *** Deprecated directives
1053 The %error-verbose directive is deprecated in favor of '%define
1054 parse.error verbose' since Bison 3.0, but no warning was issued.
1056 The '%name-prefix "xx"' directive is deprecated in favor of '%define
1057 api.prefix {xx}' since Bison 3.0, but no warning was issued. These
1058 directives are slightly different, you might need to adjust your code.
1059 %name-prefix renames only symbols with external linkage, while api.prefix
1060 also renames types and macros, including YYDEBUG, YYTOKENTYPE,
1061 yytokentype, YYSTYPE, YYLTYPE, etc.
1063 Users of Flex that move from '%name-prefix "xx"' to '%define api.prefix
1064 {xx}' will typically have to update YY_DECL from
1066 #define YY_DECL int xxlex (YYSTYPE *yylval, YYLTYPE *yylloc)
1070 #define YY_DECL int xxlex (XXSTYPE *yylval, XXLTYPE *yylloc)
1072 *** Deprecated %define variable names
1074 The following variables, mostly related to parsers in Java, have been
1075 renamed for consistency. Backward compatibility is ensured, but upgrading
1078 abstract -> api.parser.abstract
1079 annotations -> api.parser.annotations
1080 extends -> api.parser.extends
1081 final -> api.parser.final
1082 implements -> api.parser.implements
1083 parser_class_name -> api.parser.class
1084 public -> api.parser.public
1085 strictfp -> api.parser.strictfp
1089 *** Generation of fix-its for IDEs/Editors
1091 When given the new option -ffixit (aka -fdiagnostics-parseable-fixits),
1092 bison now generates machine readable editing instructions to fix some
1093 issues. Currently, this is mostly limited to updating deprecated
1094 directives and removing duplicates. For instance:
1098 %define parser_class_name "Parser"
1099 %define api.parser.class "Parser"
1103 See the "fix-it:" lines below:
1105 $ bison -ffixit foo.y
1106 foo.y:1.1-14: warning: deprecated directive, use '%define parse.error verbose' [-Wdeprecated]
1109 fix-it:"foo.y":{1:1-1:15}:"%define parse.error verbose"
1110 foo.y:2.1-34: warning: deprecated directive, use '%define api.parser.class {Parser}' [-Wdeprecated]
1111 %define parser_class_name "Parser"
1112 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1113 fix-it:"foo.y":{2:1-2:35}:"%define api.parser.class {Parser}"
1114 foo.y:3.1-33: error: %define variable 'api.parser.class' redefined
1115 %define api.parser.class "Parser"
1116 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1117 foo.y:2.1-34: previous definition
1118 %define parser_class_name "Parser"
1119 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1120 fix-it:"foo.y":{3:1-3:34}:""
1121 foo.y: warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
1123 This uses the same output format as GCC and Clang.
1125 *** Updating grammar files
1127 Fixes can be applied on the fly. The previous example ends with the
1128 suggestion to re-run bison with the option -u/--update, which results in a
1129 cleaner grammar file.
1131 $ bison --update foo.y
1133 bison: file 'foo.y' was updated (backup: 'foo.y~')
1136 %define parse.error verbose
1137 %define api.parser.class {Parser}
1141 *** Bison is now relocatable
1143 If you pass '--enable-relocatable' to 'configure', Bison is relocatable.
1145 A relocatable program can be moved or copied to a different location on
1146 the file system. It can also be used through mount points for network
1147 sharing. It is possible to make symbolic links to the installed and moved
1148 programs, and invoke them through the symbolic link.
1150 *** %expect and %expect-rr modifiers on individual rules
1152 One can now document (and check) which rules participate in shift/reduce
1153 and reduce/reduce conflicts. This is particularly important GLR parsers,
1154 where conflicts are a normal occurrence. For example,
1170 | argument_list ',' expression
1175 Looking at the output from -v, one can see that the shift/reduce conflict
1176 here is due to the fact that the parser does not know whether to reduce
1177 arguments to argument_list until it sees the token _after_ the following
1178 ','. By marking the rule with %expect 1 (because there is a conflict in
1179 one state), we document the source of the 1 overall shift/reduce conflict.
1181 In GLR parsers, we can use %expect-rr in a rule for reduce/reduce
1182 conflicts. In this case, we mark each of the conflicting rules. For
1191 target_list '=' expr ';'
1197 | target ',' target_list
1206 | expr ',' expr_list
1214 In a statement such as
1218 the parser must reduce x to a target or an expr, but does not know which
1219 until it sees the '='. So we notate the two possible reductions to
1220 indicate that each conflicts in one rule.
1222 This feature needs user feedback, and might evolve in the future.
1224 *** C++: Actual token constructors
1226 When variants and token constructors are enabled, in addition to the
1227 type-safe named token constructors (make_ID, make_INT, etc.), we now
1228 generate genuine constructors for symbol_type.
1230 For instance with these declarations
1236 you may use these constructors:
1238 symbol_type (int token, const std::string&);
1239 symbol_type (int token, const int&);
1240 symbol_type (int token);
1242 Correct matching between token types and value types is checked via
1243 'assert'; for instance, 'symbol_type (ID, 42)' would abort. Named
1244 constructors are preferable, as they offer better type safety (for
1245 instance 'make_ID (42)' would not even compile), but symbol_type
1246 constructors may help when token types are discovered at run-time, e.g.,
1249 if (auto i = lookup_keyword (yytext))
1250 return yy::parser::symbol_type (i);
1252 return yy::parser::make_ID (yytext);
1255 *** C++: Variadic emplace
1257 If your application requires C++11 and you don't use symbol constructors,
1258 you may now use a variadic emplace for semantic values:
1260 %define api.value.type variant
1261 %token <std::pair<int, int>> PAIR
1265 int yylex (parser::semantic_type *lvalp)
1267 lvalp->emplace <std::pair<int, int>> (1, 2);
1268 return parser::token::PAIR;
1271 *** C++: Syntax error exceptions in GLR
1273 The glr.cc skeleton now supports syntax_error exceptions thrown from user
1274 actions, or from the scanner.
1276 *** More POSIX Yacc compatibility warnings
1278 More Bison specific directives are now reported with -y or -Wyacc. This
1279 change was ready since the release of Bison 3.0 in September 2015. It was
1280 delayed because Autoconf used to define YACC as `bison -y`, which resulted
1281 in numerous warnings for Bison users that use the GNU Build System.
1283 If you still experience that problem, either redefine YACC as `bison -o
1284 y.tab.c`, or pass -Wno-yacc to Bison.
1286 *** The tables yyrhs and yyphrs are back
1288 Because no Bison skeleton uses them, these tables were removed (no longer
1289 passed to the skeletons, not even computed) in 2008. However, some users
1290 have expressed interest in being able to use them in their own skeletons.
1294 *** Incorrect number of reduce/reduce conflicts
1296 On a grammar such as
1298 exp: "num" | "num" | "num"
1300 bison used to report a single RR conflict, instead of two. This is now
1301 fixed. This was the oldest (known) bug in Bison: it was there when Bison
1302 was entered in the RCS version control system, in December 1987.
1304 Some grammar files might have to adjust their %expect-rr.
1306 *** Parser directives that were not careful enough
1308 Passing invalid arguments to %nterm, for instance character literals, used
1309 to result in unclear error messages.
1313 The examples/ directory (installed in .../share/doc/bison/examples) has
1314 been restructured per language for clarity. The examples come with a
1315 README and a Makefile. Not only can they be used to toy with Bison, they
1316 can also be starting points for your own grammars.
1318 There is now a Java example, and a simple example in C based on Flex and
1319 Bison (examples/c/lexcalc/).
1325 They now use noexcept and constexpr. Please, report missing annotations.
1327 *** Symbol Declarations
1329 The syntax of the variation directives to declare symbols was overhauled
1330 for more consistency, and also better POSIX Yacc compliance (which, for
1331 instance, allows "%type" without actually providing a type). The %nterm
1332 directive, supported by Bison since its inception, is now documented and
1333 officially supported.
1335 The syntax is now as follows:
1337 %token TAG? ( ID NUMBER? STRING? )+ ( TAG ( ID NUMBER? STRING? )+ )*
1338 %left TAG? ( ID NUMBER? )+ ( TAG ( ID NUMBER? )+ )*
1339 %type TAG? ( ID | CHAR | STRING )+ ( TAG ( ID | CHAR | STRING )+ )*
1340 %nterm TAG? ID+ ( TAG ID+ )*
1342 where TAG denotes a type tag such as ‘<ival>’, ID denotes an identifier
1343 such as ‘NUM’, NUMBER a decimal or hexadecimal integer such as ‘300’ or
1344 ‘0x12d’, CHAR a character literal such as ‘'+'’, and STRING a string
1345 literal such as ‘"number"’. The post-fix quantifiers are ‘?’ (zero or
1346 one), ‘*’ (zero or more) and ‘+’ (one or more).
1349 * Noteworthy changes in release 3.2.4 (2018-12-24) [stable]
1353 Fix the move constructor of symbol_type.
1355 Always provide a copy constructor for symbol_type, even in modern C++.
1358 * Noteworthy changes in release 3.2.3 (2018-12-18) [stable]
1362 Properly support token constructors in C++ with types that include commas
1363 (e.g., std::pair<int, int>). A regression introduced in Bison 3.2.
1366 * Noteworthy changes in release 3.2.2 (2018-11-21) [stable]
1370 C++ portability issues.
1373 * Noteworthy changes in release 3.2.1 (2018-11-09) [stable]
1377 Several portability issues have been fixed in the build system, in the
1378 test suite, and in the generated parsers in C++.
1381 * Noteworthy changes in release 3.2 (2018-10-29) [stable]
1383 ** Backward incompatible changes
1385 Support for DJGPP, which has been unmaintained and untested for years, is
1386 obsolete. Unless there is activity to revive it, it will be removed.
1390 %printers should use yyo rather than yyoutput to denote the output stream.
1392 Variant-based symbols in C++ should use emplace() rather than build().
1394 In C++ parsers, parser::operator() is now a synonym for the parser::parse.
1398 A new section, "A Simple C++ Example", is a tutorial for parsers in C++.
1400 A comment in the generated code now emphasizes that users should not
1401 depend upon non-documented implementation details, such as macros starting
1406 *** C++: Support for move semantics (lalr1.cc)
1408 The lalr1.cc skeleton now fully supports C++ move semantics, while
1409 maintaining compatibility with C++98. You may now store move-only types
1410 when using Bison's variants. For instance:
1417 %skeleton "lalr1.cc"
1418 %define api.value.type variant
1422 %token <int> INT "int";
1423 %type <std::unique_ptr<int>> int;
1424 %type <std::vector<std::unique_ptr<int>>> list;
1428 | list int { $$ = std::move($1); $$.emplace_back(std::move($2)); }
1430 int: "int" { $$ = std::make_unique<int>($1); }
1432 *** C++: Implicit move of right-hand side values (lalr1.cc)
1434 In modern C++ (C++11 and later), you should always use 'std::move' with
1435 the values of the right-hand side symbols ($1, $2, etc.), as they will be
1436 popped from the stack anyway. Using 'std::move' is mandatory for
1437 move-only types such as unique_ptr, and it provides a significant speedup
1438 for large types such as std::string, or std::vector, etc.
1440 If '%define api.value.automove' is set, every occurrence '$n' is replaced
1441 by 'std::move ($n)'. The second rule in the previous grammar can be
1444 list: list int { $$ = $1; $$.emplace_back($2); }
1446 With automove enabled, the semantic values are no longer lvalues, so do
1447 not use the swap idiom:
1449 list: list int { std::swap($$, $1); $$.emplace_back($2); }
1451 This idiom is anyway obsolete: it is preferable to move than to swap.
1453 A warning is issued when automove is enabled, and a value is used several
1456 input.yy:16.31-32: warning: multiple occurrences of $2 with api.value.automove enabled [-Wother]
1457 exp: "twice" exp { $$ = $2 + $2; }
1460 Enabling api.value.automove does not require support for modern C++. The
1461 generated code is valid C++98/03, but will use copies instead of moves.
1463 The new examples/c++/variant-11.yy shows these features in action.
1465 *** C++: The implicit default semantic action is always run
1467 When variants are enabled, the default action was not run, so
1475 It now behaves like in all the other cases, as
1477 exp: "number" { $$ = $1; }
1479 possibly using std::move if automove is enabled.
1481 We do not expect backward compatibility issues. However, beware of
1482 forward compatibility issues: if you rely on default actions with
1483 variants, be sure to '%require "3.2"' to avoid older versions of Bison to
1484 generate incorrect parsers.
1486 *** C++: Renaming location.hh
1488 When both %defines and %locations are enabled, Bison generates a
1489 location.hh file. If you don't use locations outside of the parser, you
1490 may avoid its creation with:
1492 %define api.location.file none
1494 However this file is useful if, for instance, your parser builds an AST
1495 decorated with locations: you may use Bison's location independently of
1496 Bison's parser. You can now give it another name, for instance:
1498 %define api.location.file "my-location.hh"
1500 This name can have directory components, and even be absolute. The name
1501 under which the location file is included is controlled by
1502 api.location.include.
1504 This way it is possible to have several parsers share the same location
1507 For instance, in src/foo/parser.hh, generate the include/ast/loc.hh file:
1510 %define api.namespace {foo}
1511 %define api.location.file "include/ast/loc.hh"
1512 %define api.location.include {<ast/loc.hh>}
1514 and use it in src/bar/parser.hh:
1517 %define api.namespace {bar}
1518 %code requires {#include <ast/loc.hh>}
1519 %define api.location.type {bar::location}
1521 Absolute file names are supported, so in your Makefile, passing the flag
1522 -Dapi.location.file='"$(top_srcdir)/include/ast/location.hh"' to bison is
1525 *** C++: stack.hh and position.hh are deprecated
1527 When asked to generate a header file (%defines), the lalr1.cc skeleton
1528 generates a stack.hh file. This file had no interest for users; it is now
1529 made useless: its content is included in the parser definition. It is
1530 still generated for backward compatibility.
1532 When in addition to %defines, location support is requested (%locations),
1533 the file position.hh is also generated. It is now also useless: its
1534 content is now included in location.hh.
1536 These files are no longer generated when your grammar file requires at
1537 least Bison 3.2 (%require "3.2").
1541 Portability issues on MinGW and VS2015.
1543 Portability issues in the test suite.
1545 Portability/warning issues with Flex.
1548 * Noteworthy changes in release 3.1 (2018-08-27) [stable]
1550 ** Backward incompatible changes
1552 Compiling Bison now requires a C99 compiler---as announced during the
1553 release of Bison 3.0, five years ago. Generated parsers do not require a
1556 Support for DJGPP, which has been unmaintained and untested for years, is
1557 obsolete. Unless there is activity to revive it, the next release of Bison
1558 will have it removed.
1562 *** Typed midrule actions
1564 Because their type is unknown to Bison, the values of midrule actions are
1565 not treated like the others: they don't have %printer and %destructor
1566 support. It also prevents C++ (Bison) variants to handle them properly.
1568 Typed midrule actions address these issues. Instead of:
1570 exp: { $<ival>$ = 1; } { $<ival>$ = 2; } { $$ = $<ival>1 + $<ival>2; }
1574 exp: <ival>{ $$ = 1; } <ival>{ $$ = 2; } { $$ = $1 + $2; }
1576 *** Reports include the type of the symbols
1578 The sections about terminal and nonterminal symbols of the '*.output' file
1579 now specify their declared type. For instance, for:
1583 the report now shows '<ival>':
1585 Terminals, with rules where they appear
1589 *** Diagnostics about useless rules
1591 In the following grammar, the 'exp' nonterminal is trivially useless. So,
1592 of course, its rules are useless too.
1596 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1598 Previously all the useless rules were reported, including those whose
1599 left-hand side is the 'exp' nonterminal:
1601 warning: 1 nonterminal useless in grammar [-Wother]
1602 warning: 4 rules useless in grammar [-Wother]
1603 2.14-16: warning: nonterminal useless in grammar: exp [-Wother]
1606 2.14-16: warning: rule useless in grammar [-Wother]
1609 3.6-16: warning: rule useless in grammar [-Wother]
1610 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1612 3.20-30: warning: rule useless in grammar [-Wother]
1613 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1615 3.34-44: warning: rule useless in grammar [-Wother]
1616 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1619 Now, rules whose left-hand side symbol is useless are no longer reported
1620 as useless. The locations of the errors have also been adjusted to point
1621 to the first use of the nonterminal as a left-hand side of a rule:
1623 warning: 1 nonterminal useless in grammar [-Wother]
1624 warning: 4 rules useless in grammar [-Wother]
1625 3.1-3: warning: nonterminal useless in grammar: exp [-Wother]
1626 exp: exp '+' exp | exp '-' exp | '(' exp ')'
1628 2.14-16: warning: rule useless in grammar [-Wother]
1632 *** C++: Generated parsers can be compiled with -fno-exceptions (lalr1.cc)
1634 When compiled with exceptions disabled, the generated parsers no longer
1635 uses try/catch clauses.
1637 Currently only GCC and Clang are supported.
1641 *** A demonstration of variants
1643 A new example was added (installed in .../share/doc/bison/examples),
1644 'variant.yy', which shows how to use (Bison) variants in C++.
1646 The other examples were made nicer to read.
1648 *** Some features are no longer 'experimental'
1650 The following features, mature enough, are no longer flagged as
1651 experimental in the documentation: push parsers, default %printer and
1652 %destructor (typed: <*> and untyped: <>), %define api.value.type union and
1653 variant, Java parsers, XML output, LR family (lr, ielr, lalr), and
1654 semantic predicates (%?).
1658 *** GLR: Predicates support broken by #line directives
1660 Predicates (%?) in GLR such as
1663 %? {new_syntax} 'w' id new_args
1664 | %?{!new_syntax} 'w' id old_args
1666 were issued with #lines in the middle of C code.
1668 *** Printer and destructor with broken #line directives
1670 The #line directives were not properly escaped when emitting the code for
1671 %printer/%destructor, which resulted in compiler errors if there are
1672 backslashes or double-quotes in the grammar file name.
1674 *** Portability on ICC
1676 The Intel compiler claims compatibility with GCC, yet rejects its _Pragma.
1677 Generated parsers now work around this.
1681 There were several small fixes in the test suite and in the build system,
1682 many warnings in bison and in the generated parsers were eliminated. The
1683 documentation also received its share of minor improvements.
1685 Useless code was removed from C++ parsers, and some of the generated
1686 constructors are more 'natural'.
1689 * Noteworthy changes in release 3.0.5 (2018-05-27) [stable]
1693 *** C++: Fix support of 'syntax_error'
1695 One incorrect 'inline' resulted in linking errors about the constructor of
1696 the syntax_error exception.
1698 *** C++: Fix warnings
1700 GCC 7.3 (with -O1 or -O2 but not -O0 or -O3) issued null-dereference
1701 warnings about yyformat being possibly null. It also warned about the
1702 deprecated implicit definition of copy constructors when there's a
1703 user-defined (copy) assignment operator.
1705 *** Location of errors
1707 In C++ parsers, out-of-bounds errors can happen when a rule with an empty
1708 ride-hand side raises a syntax error. The behavior of the default parser
1709 (yacc.c) in such a condition was undefined.
1711 Now all the parsers match the behavior of glr.c: @$ is used as the
1712 location of the error. This handles gracefully rules with and without
1715 *** Portability fixes in the test suite
1717 On some platforms, some Java and/or C++ tests were failing.
1720 * Noteworthy changes in release 3.0.4 (2015-01-23) [stable]
1724 *** C++ with Variants (lalr1.cc)
1726 Fix a compiler warning when no %destructor use $$.
1730 Several portability issues in tests were fixed.
1733 * Noteworthy changes in release 3.0.3 (2015-01-15) [stable]
1737 *** C++ with Variants (lalr1.cc)
1739 Problems with %destructor and '%define parse.assert' have been fixed.
1741 *** Named %union support (yacc.c, glr.c)
1743 Bison 3.0 introduced a regression on named %union such as
1745 %union foo { int ival; };
1747 The possibility to use a name was introduced "for Yacc compatibility".
1748 It is however not required by POSIX Yacc, and its usefulness is not clear.
1750 *** %define api.value.type union with %defines (yacc.c, glr.c)
1752 The C parsers were broken when %defines was used together with "%define
1753 api.value.type union".
1755 *** Redeclarations are reported in proper order
1763 bison used to report:
1765 foo.yy:2.10-11: error: %printer redeclaration for FOO
1768 foo.yy:3.10-11: previous declaration
1772 Now, the "previous" declaration is always the first one.
1777 Bison now installs various files in its docdir (which defaults to
1778 '/usr/local/share/doc/bison'), including the three fully blown examples
1779 extracted from the documentation:
1782 Reverse Polish Calculator, a simple introductory example.
1784 Multi-function Calc, a calculator with memory and functions and located
1787 a calculator in C++ using variant support and token constructors.
1790 * Noteworthy changes in release 3.0.2 (2013-12-05) [stable]
1794 *** Generated source files when errors are reported
1796 When warnings are issued and -Werror is set, bison would still generate
1797 the source files (*.c, *.h...). As a consequence, some runs of "make"
1798 could fail the first time, but not the second (as the files were generated
1801 This is fixed: bison no longer generates this source files, but, of
1802 course, still produces the various reports (*.output, *.xml, etc.).
1804 *** %empty is used in reports
1806 Empty right-hand sides are denoted by '%empty' in all the reports (text,
1807 dot, XML and formats derived from it).
1809 *** YYERROR and variants
1811 When C++ variant support is enabled, an error triggered via YYERROR, but
1812 not caught via error recovery, resulted in a double deletion.
1815 * Noteworthy changes in release 3.0.1 (2013-11-12) [stable]
1819 *** Errors in caret diagnostics
1821 On some platforms, some errors could result in endless diagnostics.
1823 *** Fixes of the -Werror option
1825 Options such as "-Werror -Wno-error=foo" were still turning "foo"
1826 diagnostics into errors instead of warnings. This is fixed.
1828 Actually, for consistency with GCC, "-Wno-error=foo -Werror" now also
1829 leaves "foo" diagnostics as warnings. Similarly, with "-Werror=foo
1830 -Wno-error", "foo" diagnostics are now errors.
1834 As demonstrated in the documentation, one can now leave spaces between
1839 The yacc.1 man page is no longer installed if --disable-yacc was
1842 *** Fixes in the test suite
1844 Bugs and portability issues.
1847 * Noteworthy changes in release 3.0 (2013-07-25) [stable]
1849 ** WARNING: Future backward-incompatibilities!
1851 Like other GNU packages, Bison will start using some of the C99 features
1852 for its own code, especially the definition of variables after statements.
1853 The generated C parsers still aim at C90.
1855 ** Backward incompatible changes
1857 *** Obsolete features
1859 Support for YYFAIL is removed (deprecated in Bison 2.4.2): use YYERROR.
1861 Support for yystype and yyltype is removed (deprecated in Bison 1.875):
1862 use YYSTYPE and YYLTYPE.
1864 Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
1865 1.875): use %lex-param, %parse-param, or %param.
1867 Missing semicolons at the end of actions are no longer added (as announced
1868 in the release 2.5).
1870 *** Use of YACC='bison -y'
1872 TL;DR: With Autoconf <= 2.69, pass -Wno-yacc to (AM_)YFLAGS if you use
1875 Traditional Yacc generates 'y.tab.c' whatever the name of the input file.
1876 Therefore Makefiles written for Yacc expect 'y.tab.c' (and possibly
1877 'y.tab.h' and 'y.output') to be generated from 'foo.y'.
1879 To this end, for ages, AC_PROG_YACC, Autoconf's macro to look for an
1880 implementation of Yacc, was using Bison as 'bison -y'. While it does
1881 ensure compatible output file names, it also enables warnings for
1882 incompatibilities with POSIX Yacc. In other words, 'bison -y' triggers
1883 warnings for Bison extensions.
1885 Autoconf 2.70+ fixes this incompatibility by using YACC='bison -o y.tab.c'
1886 (which also generates 'y.tab.h' and 'y.output' when needed).
1887 Alternatively, disable Yacc warnings by passing '-Wno-yacc' to your Yacc
1888 flags (YFLAGS, or AM_YFLAGS with Automake).
1892 *** The epilogue is no longer affected by internal #defines (glr.c)
1894 The glr.c skeleton uses defines such as #define yylval (yystackp->yyval) in
1895 generated code. These weren't properly undefined before the inclusion of
1896 the user epilogue, so functions such as the following were butchered by the
1897 preprocessor expansion:
1899 int yylex (YYSTYPE *yylval);
1901 This is fixed: yylval, yynerrs, yychar, and yylloc are now valid
1902 identifiers for user-provided variables.
1904 *** stdio.h is no longer needed when locations are enabled (yacc.c)
1906 Changes in Bison 2.7 introduced a dependency on FILE and fprintf when
1907 locations are enabled. This is fixed.
1909 *** Warnings about useless %pure-parser/%define api.pure are restored
1911 ** Diagnostics reported by Bison
1913 Most of these features were contributed by Théophile Ranquet and Victor
1918 Version 2.7 introduced caret errors, for a prettier output. These are now
1919 activated by default. The old format can still be used by invoking Bison
1920 with -fno-caret (or -fnone).
1922 Some error messages that reproduced excerpts of the grammar are now using
1923 the caret information only. For instance on:
1930 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
1931 in.y:2.12-14: warning: rule useless in parser due to conflicts: exp: 'a' [-Wother]
1935 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
1936 in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
1940 and "bison -fno-caret" reports:
1942 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
1943 in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
1945 *** Enhancements of the -Werror option
1947 The -Werror=CATEGORY option is now recognized, and will treat specified
1948 warnings as errors. The warnings need not have been explicitly activated
1949 using the -W option, this is similar to what GCC 4.7 does.
1951 For example, given the following command line, Bison will treat both
1952 warnings related to POSIX Yacc incompatibilities and S/R conflicts as
1953 errors (and only those):
1955 $ bison -Werror=yacc,error=conflicts-sr input.y
1957 If no categories are specified, -Werror will make all active warnings into
1958 errors. For example, the following line does the same the previous example:
1960 $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y
1962 (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)
1964 Note that the categories in this -Werror option may not be prefixed with
1965 "no-". However, -Wno-error[=CATEGORY] is valid.
1967 Note that -y enables -Werror=yacc. Therefore it is now possible to require
1968 Yacc-like behavior (e.g., always generate y.tab.c), but to report
1969 incompatibilities as warnings: "-y -Wno-error=yacc".
1971 *** The display of warnings is now richer
1973 The option that controls a given warning is now displayed:
1975 foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
1977 In the case of warnings treated as errors, the prefix is changed from
1978 "warning: " to "error: ", and the suffix is displayed, in a manner similar
1979 to GCC, as [-Werror=CATEGORY].
1981 For instance, where the previous version of Bison would report (and exit
1984 bison: warnings being treated as errors
1985 input.y:1.1: warning: stray ',' treated as white space
1989 input.y:1.1: error: stray ',' treated as white space [-Werror=other]
1991 *** Deprecated constructs
1993 The new 'deprecated' warning category flags obsolete constructs whose
1994 support will be discontinued. It is enabled by default. These warnings
1995 used to be reported as 'other' warnings.
1997 *** Useless semantic types
1999 Bison now warns about useless (uninhabited) semantic types. Since
2000 semantic types are not declared to Bison (they are defined in the opaque
2001 %union structure), it is %printer/%destructor directives about useless
2002 types that trigger the warning:
2006 %printer {} <type1> <type3>
2007 %destructor {} <type2> <type4>
2009 nterm: term { $$ = $1; };
2011 3.28-34: warning: type <type3> is used, but is not associated to any symbol
2012 4.28-34: warning: type <type4> is used, but is not associated to any symbol
2014 *** Undefined but unused symbols
2016 Bison used to raise an error for undefined symbols that are not used in
2017 the grammar. This is now only a warning.
2020 %destructor {} symbol2
2021 %type <type> symbol3
2025 *** Useless destructors or printers
2027 Bison now warns about useless destructors or printers. In the following
2028 example, the printer for <type1>, and the destructor for <type2> are
2029 useless: all symbols of <type1> (token1) already have a printer, and all
2030 symbols of type <type2> (token2) already have a destructor.
2032 %token <type1> token1
2036 %printer {} token1 <type1> <type3>
2037 %destructor {} token2 <type2> <type4>
2041 The warnings and error messages about shift/reduce and reduce/reduce
2042 conflicts have been normalized. For instance on the following foo.y file:
2046 exp: exp '+' exp | '0' | '0';
2048 compare the previous version of bison:
2051 foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
2052 $ bison -Werror foo.y
2053 bison: warnings being treated as errors
2054 foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
2056 with the new behavior:
2059 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
2060 foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
2061 $ bison -Werror foo.y
2062 foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
2063 foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]
2065 When %expect or %expect-rr is used, such as with bar.y:
2070 exp: exp '+' exp | '0' | '0';
2075 bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
2076 bar.y: expected 0 shift/reduce conflicts
2077 bar.y: expected 0 reduce/reduce conflicts
2082 bar.y: error: shift/reduce conflicts: 1 found, 0 expected
2083 bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
2085 ** Incompatibilities with POSIX Yacc
2087 The 'yacc' category is no longer part of '-Wall', enable it explicitly
2090 ** Additional yylex/yyparse arguments
2092 The new directive %param declares additional arguments to both yylex and
2093 yyparse. The %lex-param, %parse-param, and %param directives support one
2094 or more arguments. Instead of
2096 %lex-param {arg1_type *arg1}
2097 %lex-param {arg2_type *arg2}
2098 %parse-param {arg1_type *arg1}
2099 %parse-param {arg2_type *arg2}
2103 %param {arg1_type *arg1} {arg2_type *arg2}
2105 ** Types of values for %define variables
2107 Bison used to make no difference between '%define foo bar' and '%define
2108 foo "bar"'. The former is now called a 'keyword value', and the latter a
2109 'string value'. A third kind was added: 'code values', such as '%define
2112 Keyword variables are used for fixed value sets, e.g.,
2114 %define lr.type lalr
2116 Code variables are used for value in the target language, e.g.,
2118 %define api.value.type {struct semantic_type}
2120 String variables are used remaining cases, e.g. file names.
2122 ** Variable api.token.prefix
2124 The variable api.token.prefix changes the way tokens are identified in
2125 the generated files. This is especially useful to avoid collisions
2126 with identifiers in the target language. For instance
2128 %token FILE for ERROR
2129 %define api.token.prefix {TOK_}
2131 start: FILE for ERROR;
2133 will generate the definition of the symbols TOK_FILE, TOK_for, and
2134 TOK_ERROR in the generated sources. In particular, the scanner must
2135 use these prefixed token names, although the grammar itself still
2136 uses the short names (as in the sample rule given above).
2138 ** Variable api.value.type
2140 This new %define variable supersedes the #define macro YYSTYPE. The use
2141 of YYSTYPE is discouraged. In particular, #defining YYSTYPE *and* either
2142 using %union or %defining api.value.type results in undefined behavior.
2144 Either define api.value.type, or use "%union":
2151 %token <ival> INT "integer"
2152 %token <sval> STRING "string"
2153 %printer { fprintf (yyo, "%d", $$); } <ival>
2154 %destructor { free ($$); } <sval>
2157 yylval.ival = 42; return INT;
2158 yylval.sval = "42"; return STRING;
2160 The %define variable api.value.type supports both keyword and code values.
2162 The keyword value 'union' means that the user provides genuine types, not
2163 union member names such as "ival" and "sval" above (WARNING: will fail if
2164 -y/--yacc/%yacc is enabled).
2166 %define api.value.type union
2167 %token <int> INT "integer"
2168 %token <char *> STRING "string"
2169 %printer { fprintf (yyo, "%d", $$); } <int>
2170 %destructor { free ($$); } <char *>
2173 yylval.INT = 42; return INT;
2174 yylval.STRING = "42"; return STRING;
2176 The keyword value variant is somewhat equivalent, but for C++ special
2177 provision is made to allow classes to be used (more about this below).
2179 %define api.value.type variant
2180 %token <int> INT "integer"
2181 %token <std::string> STRING "string"
2183 Code values (in braces) denote user defined types. This is where YYSTYPE
2201 %define api.value.type {struct my_value}
2202 %token <u.ival> INT "integer"
2203 %token <u.sval> STRING "string"
2204 %printer { fprintf (yyo, "%d", $$); } <u.ival>
2205 %destructor { free ($$); } <u.sval>
2208 yylval.u.ival = 42; return INT;
2209 yylval.u.sval = "42"; return STRING;
2211 ** Variable parse.error
2213 This variable controls the verbosity of error messages. The use of the
2214 %error-verbose directive is deprecated in favor of "%define parse.error
2217 ** Deprecated %define variable names
2219 The following variables have been renamed for consistency. Backward
2220 compatibility is ensured, but upgrading is recommended.
2222 lr.default-reductions -> lr.default-reduction
2223 lr.keep-unreachable-states -> lr.keep-unreachable-state
2224 namespace -> api.namespace
2225 stype -> api.value.type
2227 ** Semantic predicates
2229 Contributed by Paul Hilfinger.
2231 The new, experimental, semantic-predicate feature allows actions of the
2232 form "%?{ BOOLEAN-EXPRESSION }", which cause syntax errors (as for
2233 YYERROR) if the expression evaluates to 0, and are evaluated immediately
2234 in GLR parsers, rather than being deferred. The result is that they allow
2235 the programmer to prune possible parses based on the values of run-time
2238 ** The directive %expect-rr is now an error in non GLR mode
2240 It used to be an error only if used in non GLR mode, _and_ if there are
2241 reduce/reduce conflicts.
2243 ** Tokens are numbered in their order of appearance
2245 Contributed by Valentin Tolmer.
2247 With '%token A B', A had a number less than the one of B. However,
2248 precedence declarations used to generate a reversed order. This is now
2249 fixed, and introducing tokens with any of %token, %left, %right,
2250 %precedence, or %nonassoc yields the same result.
2252 When mixing declarations of tokens with a literal character (e.g., 'a') or
2253 with an identifier (e.g., B) in a precedence declaration, Bison numbered
2254 the literal characters first. For example
2258 would lead to the tokens declared in this order: 'c' 'd' A B. Again, the
2259 input order is now preserved.
2261 These changes were made so that one can remove useless precedence and
2262 associativity declarations (i.e., map %nonassoc, %left or %right to
2263 %precedence, or to %token) and get exactly the same output.
2265 ** Useless precedence and associativity
2267 Contributed by Valentin Tolmer.
2269 When developing and maintaining a grammar, useless associativity and
2270 precedence directives are common. They can be a nuisance: new ambiguities
2271 arising are sometimes masked because their conflicts are resolved due to
2272 the extra precedence or associativity information. Furthermore, it can
2273 hinder the comprehension of a new grammar: one will wonder about the role
2274 of a precedence, where in fact it is useless. The following changes aim
2275 at detecting and reporting these extra directives.
2277 *** Precedence warning category
2279 A new category of warning, -Wprecedence, was introduced. It flags the
2280 useless precedence and associativity directives.
2282 *** Useless associativity
2284 Bison now warns about symbols with a declared associativity that is never
2285 used to resolve conflicts. In that case, using %precedence is sufficient;
2286 the parsing tables will remain unchanged. Solving these warnings may raise
2287 useless precedence warnings, as the symbols no longer have associativity.
2301 warning: useless associativity for '+', use %precedence [-Wprecedence]
2305 *** Useless precedence
2307 Bison now warns about symbols with a declared precedence and no declared
2308 associativity (i.e., declared with %precedence), and whose precedence is
2309 never used. In that case, the symbol can be safely declared with %token
2310 instead, without modifying the parsing tables. For example:
2314 exp: "var" '=' "number";
2318 warning: useless precedence for '=' [-Wprecedence]
2322 *** Useless precedence and associativity
2324 In case of both useless precedence and associativity, the issue is flagged
2329 exp: "var" '=' "number";
2333 warning: useless precedence and associativity for '=' [-Wprecedence]
2339 With help from Joel E. Denny and Gabriel Rassoul.
2341 Empty rules (i.e., with an empty right-hand side) can now be explicitly
2342 marked by the new %empty directive. Using %empty on a non-empty rule is
2343 an error. The new -Wempty-rule warning reports empty rules without
2344 %empty. On the following grammar:
2354 3.4-5: warning: empty rule without %empty [-Wempty-rule]
2357 5.8-13: error: %empty on non-empty rule
2361 ** Java skeleton improvements
2363 The constants for token names were moved to the Lexer interface. Also, it
2364 is possible to add code to the parser's constructors using "%code init"
2365 and "%define init_throws".
2366 Contributed by Paolo Bonzini.
2368 The Java skeleton now supports push parsing.
2369 Contributed by Dennis Heimbigner.
2371 ** C++ skeletons improvements
2373 *** The parser header is no longer mandatory (lalr1.cc, glr.cc)
2375 Using %defines is now optional. Without it, the needed support classes
2376 are defined in the generated parser, instead of additional files (such as
2377 location.hh, position.hh and stack.hh).
2379 *** Locations are no longer mandatory (lalr1.cc, glr.cc)
2381 Both lalr1.cc and glr.cc no longer require %location.
2383 *** syntax_error exception (lalr1.cc)
2385 The C++ parser features a syntax_error exception, which can be
2386 thrown from the scanner or from user rules to raise syntax errors.
2387 This facilitates reporting errors caught in sub-functions (e.g.,
2388 rejecting too large integral literals from a conversion function
2389 used by the scanner, or rejecting invalid combinations from a
2390 factory invoked by the user actions).
2392 *** %define api.value.type variant
2394 This is based on a submission from Michiel De Wilde. With help
2395 from Théophile Ranquet.
2397 In this mode, complex C++ objects can be used as semantic values. For
2400 %token <::std::string> TEXT;
2401 %token <int> NUMBER;
2402 %token SEMICOLON ";"
2403 %type <::std::string> item;
2404 %type <::std::list<std::string>> list;
2407 list { std::cout << $1 << std::endl; }
2411 %empty { /* Generates an empty string list. */ }
2412 | list item ";" { std::swap ($$, $1); $$.push_back ($2); }
2416 TEXT { std::swap ($$, $1); }
2417 | NUMBER { $$ = string_cast ($1); }
2420 *** %define api.token.constructor
2422 When variants are enabled, Bison can generate functions to build the
2423 tokens. This guarantees that the token type (e.g., NUMBER) is consistent
2424 with the semantic value (e.g., int):
2426 parser::symbol_type yylex ()
2428 parser::location_type loc = ...;
2430 return parser::make_TEXT ("Hello, world!", loc);
2432 return parser::make_NUMBER (42, loc);
2434 return parser::make_SEMICOLON (loc);
2440 There are operator- and operator-= for 'location'. Negative line/column
2441 increments can no longer underflow the resulting value.
2444 * Noteworthy changes in release 2.7.1 (2013-04-15) [stable]
2448 *** Fix compiler attribute portability (yacc.c)
2450 With locations enabled, __attribute__ was used unprotected.
2452 *** Fix some compiler warnings (lalr1.cc)
2455 * Noteworthy changes in release 2.7 (2012-12-12) [stable]
2459 Warnings about uninitialized yylloc in yyparse have been fixed.
2461 Restored C90 compliance (yet no report was ever made).
2463 ** Diagnostics are improved
2465 Contributed by Théophile Ranquet.
2467 *** Changes in the format of error messages
2469 This used to be the format of many error reports:
2471 input.y:2.7-12: %type redeclaration for exp
2472 input.y:1.7-12: previous declaration
2476 input.y:2.7-12: error: %type redeclaration for exp
2477 input.y:1.7-12: previous declaration
2479 *** New format for error reports: carets
2481 Caret errors have been added to Bison:
2483 input.y:2.7-12: error: %type redeclaration for exp
2486 input.y:1.7-12: previous declaration
2492 input.y:3.20-23: error: ambiguous reference: '$exp'
2493 exp: exp '+' exp { $exp = $1 + $3; };
2495 input.y:3.1-3: refers to: $exp at $$
2496 exp: exp '+' exp { $exp = $1 + $3; };
2498 input.y:3.6-8: refers to: $exp at $1
2499 exp: exp '+' exp { $exp = $1 + $3; };
2501 input.y:3.14-16: refers to: $exp at $3
2502 exp: exp '+' exp { $exp = $1 + $3; };
2505 The default behavior for now is still not to display these unless
2506 explicitly asked with -fcaret (or -fall). However, in a later release, it
2507 will be made the default behavior (but may still be deactivated with
2510 ** New value for %define variable: api.pure full
2512 The %define variable api.pure requests a pure (reentrant) parser. However,
2513 for historical reasons, using it in a location-tracking Yacc parser
2514 resulted in a yyerror function that did not take a location as a
2515 parameter. With this new value, the user may request a better pure parser,
2516 where yyerror does take a location as a parameter (in location-tracking
2519 The use of "%define api.pure true" is deprecated in favor of this new
2520 "%define api.pure full".
2522 ** New %define variable: api.location.type (glr.cc, lalr1.cc, lalr1.java)
2524 The %define variable api.location.type defines the name of the type to use
2525 for locations. When defined, Bison no longer generates the position.hh
2526 and location.hh files, nor does the parser will include them: the user is
2527 then responsible to define her type.
2529 This can be used in programs with several parsers to factor their location
2530 and position files: let one of them generate them, and the others just use
2533 This feature was actually introduced, but not documented, in Bison 2.5,
2534 under the name "location_type" (which is maintained for backward
2537 For consistency, lalr1.java's %define variables location_type and
2538 position_type are deprecated in favor of api.location.type and
2541 ** Exception safety (lalr1.cc)
2543 The parse function now catches exceptions, uses the %destructors to
2544 release memory (the lookahead symbol and the symbols pushed on the stack)
2545 before re-throwing the exception.
2547 This feature is somewhat experimental. User feedback would be
2550 ** Graph improvements in DOT and XSLT
2552 Contributed by Théophile Ranquet.
2554 The graphical presentation of the states is more readable: their shape is
2555 now rectangular, the state number is clearly displayed, and the items are
2556 numbered and left-justified.
2558 The reductions are now explicitly represented as transitions to other
2559 diamond shaped nodes.
2561 These changes are present in both --graph output and xml2dot.xsl XSLT
2562 processing, with minor (documented) differences.
2564 ** %language is no longer an experimental feature.
2566 The introduction of this feature, in 2.4, was four years ago. The
2567 --language option and the %language directive are no longer experimental.
2571 The sections about shift/reduce and reduce/reduce conflicts resolution
2572 have been fixed and extended.
2574 Although introduced more than four years ago, XML and Graphviz reports
2575 were not properly documented.
2577 The translation of midrule actions is now described.
2580 * Noteworthy changes in release 2.6.5 (2012-11-07) [stable]
2582 We consider compiler warnings about Bison generated parsers to be bugs.
2583 Rather than working around them in your own project, please consider
2584 reporting them to us.
2588 Warnings about uninitialized yylval and/or yylloc for push parsers with a
2589 pure interface have been fixed for GCC 4.0 up to 4.8, and Clang 2.9 to
2592 Other issues in the test suite have been addressed.
2594 Null characters are correctly displayed in error messages.
2596 When possible, yylloc is correctly initialized before calling yylex. It
2597 is no longer necessary to initialize it in the %initial-action.
2600 * Noteworthy changes in release 2.6.4 (2012-10-23) [stable]
2602 Bison 2.6.3's --version was incorrect. This release fixes this issue.
2605 * Noteworthy changes in release 2.6.3 (2012-10-22) [stable]
2609 Bugs and portability issues in the test suite have been fixed.
2611 Some errors in translations have been addressed, and --help now directs
2612 users to the appropriate place to report them.
2614 Stray Info files shipped by accident are removed.
2616 Incorrect definitions of YY_, issued by yacc.c when no parser header is
2617 generated, are removed.
2619 All the generated headers are self-contained.
2621 ** Header guards (yacc.c, glr.c, glr.cc)
2623 In order to avoid collisions, the header guards are now
2624 YY_<PREFIX>_<FILE>_INCLUDED, instead of merely <PREFIX>_<FILE>.
2625 For instance the header generated from
2627 %define api.prefix "calc"
2628 %defines "lib/parse.h"
2630 will use YY_CALC_LIB_PARSE_H_INCLUDED as guard.
2632 ** Fix compiler warnings in the generated parser (yacc.c, glr.c)
2634 The compilation of pure parsers (%define api.pure) can trigger GCC
2637 input.c: In function 'yyparse':
2638 input.c:1503:12: warning: 'yylval' may be used uninitialized in this
2639 function [-Wmaybe-uninitialized]
2643 This is now fixed; pragmas to avoid these warnings are no longer needed.
2645 Warnings from clang ("equality comparison with extraneous parentheses" and
2646 "function declared 'noreturn' should not return") have also been
2650 * Noteworthy changes in release 2.6.2 (2012-08-03) [stable]
2654 Buffer overruns, complaints from Flex, and portability issues in the test
2655 suite have been fixed.
2657 ** Spaces in %lex- and %parse-param (lalr1.cc, glr.cc)
2659 Trailing end-of-lines in %parse-param or %lex-param would result in
2660 invalid C++. This is fixed.
2662 ** Spurious spaces and end-of-lines
2664 The generated files no longer end (nor start) with empty lines.
2667 * Noteworthy changes in release 2.6.1 (2012-07-30) [stable]
2669 Bison no longer executes user-specified M4 code when processing a grammar.
2673 In addition to the removal of the features announced in Bison 2.6, the
2674 next major release will remove the "Temporary hack for adding a semicolon
2675 to the user action", as announced in the release 2.5. Instead of:
2677 exp: exp "+" exp { $$ = $1 + $3 };
2681 exp: exp "+" exp { $$ = $1 + $3; };
2685 *** Type names are now properly escaped.
2687 *** glr.cc: set_debug_level and debug_level work as expected.
2689 *** Stray @ or $ in actions
2691 While Bison used to warn about stray $ or @ in action rules, it did not
2692 for other actions such as printers, destructors, or initial actions. It
2695 ** Type names in actions
2697 For consistency with rule actions, it is now possible to qualify $$ by a
2698 type-name in destructors, printers, and initial actions. For instance:
2700 %printer { fprintf (yyo, "(%d, %f)", $<ival>$, $<fval>$); } <*> <>;
2702 will display two values for each typed and untyped symbol (provided
2703 that YYSTYPE has both "ival" and "fval" fields).
2706 * Noteworthy changes in release 2.6 (2012-07-19) [stable]
2710 The next major release of Bison will drop support for the following
2711 deprecated features. Please report disagreements to bug-bison@gnu.org.
2715 Support for generating parsers in K&R C will be removed. Parsers
2716 generated for C support ISO C90, and are tested with ISO C99 and ISO C11
2719 *** Features deprecated since Bison 1.875
2721 The definitions of yystype and yyltype will be removed; use YYSTYPE and
2724 YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and
2725 %lex-param, will no longer be supported.
2727 Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use
2730 *** The generated header will be included (yacc.c)
2732 Instead of duplicating the content of the generated header (definition of
2733 YYSTYPE, yyparse declaration etc.), the generated parser will include it,
2734 as is already the case for GLR or C++ parsers. This change is deferred
2735 because existing versions of ylwrap (e.g., Automake 1.12.1) do not support
2738 ** Generated Parser Headers
2740 *** Guards (yacc.c, glr.c, glr.cc)
2742 The generated headers are now guarded, as is already the case for C++
2743 parsers (lalr1.cc). For instance, with --defines=foo.h:
2748 #endif /* !YY_FOO_H */
2750 *** New declarations (yacc.c, glr.c)
2752 The generated header now declares yydebug and yyparse. Both honor
2753 --name-prefix=bar_, and yield
2755 int bar_parse (void);
2759 #define yyparse bar_parse
2762 in order to facilitate the inclusion of several parser headers inside a
2763 single compilation unit.
2765 *** Exported symbols in C++
2767 The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the
2768 header, are removed, as they prevent the possibility of including several
2769 generated headers from a single compilation unit.
2773 For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no
2776 ** New %define variable: api.prefix
2778 Now that the generated headers are more complete and properly protected
2779 against multiple inclusions, constant names, such as YYSTYPE are a
2780 problem. While yyparse and others are properly renamed by %name-prefix,
2781 YYSTYPE, YYDEBUG and others have never been affected by it. Because it
2782 would introduce backward compatibility issues in projects not expecting
2783 YYSTYPE to be renamed, instead of changing the behavior of %name-prefix,
2784 it is deprecated in favor of a new %define variable: api.prefix.
2786 The following examples compares both:
2788 %name-prefix "bar_" | %define api.prefix "bar_"
2789 %token <ival> FOO %token <ival> FOO
2790 %union { int ival; } %union { int ival; }
2796 #ifndef BAR_FOO_H #ifndef BAR_FOO_H
2797 # define BAR_FOO_H # define BAR_FOO_H
2799 /* Enabling traces. */ /* Enabling traces. */
2800 # ifndef YYDEBUG | # ifndef BAR_DEBUG
2801 > # if defined YYDEBUG
2803 > # define BAR_DEBUG 1
2805 > # define BAR_DEBUG 0
2808 # define YYDEBUG 0 | # define BAR_DEBUG 0
2812 # if YYDEBUG | # if BAR_DEBUG
2813 extern int bar_debug; extern int bar_debug;
2816 /* Tokens. */ /* Tokens. */
2817 # ifndef YYTOKENTYPE | # ifndef BAR_TOKENTYPE
2818 # define YYTOKENTYPE | # define BAR_TOKENTYPE
2819 enum yytokentype { | enum bar_tokentype {
2824 #if ! defined YYSTYPE \ | #if ! defined BAR_STYPE \
2825 && ! defined YYSTYPE_IS_DECLARED | && ! defined BAR_STYPE_IS_DECLARED
2826 typedef union YYSTYPE | typedef union BAR_STYPE
2829 } YYSTYPE; | } BAR_STYPE;
2830 # define YYSTYPE_IS_DECLARED 1 | # define BAR_STYPE_IS_DECLARED 1
2833 extern YYSTYPE bar_lval; | extern BAR_STYPE bar_lval;
2835 int bar_parse (void); int bar_parse (void);
2837 #endif /* !BAR_FOO_H */ #endif /* !BAR_FOO_H */
2840 * Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
2844 The next major release will drop support for generating parsers in K&R C.
2846 ** yacc.c: YYBACKUP works as expected.
2848 ** glr.c improvements:
2850 *** Location support is eliminated when not requested:
2852 GLR parsers used to include location-related code even when locations were
2853 not requested, and therefore not even usable.
2855 *** __attribute__ is preserved:
2857 __attribute__ is no longer disabled when __STRICT_ANSI__ is defined (i.e.,
2858 when -std is passed to GCC).
2860 ** lalr1.java: several fixes:
2862 The Java parser no longer throws ArrayIndexOutOfBoundsException if the
2863 first token leads to a syntax error. Some minor clean ups.
2867 *** C++11 compatibility:
2869 C and C++ parsers use "nullptr" instead of "0" when __cplusplus is 201103L
2874 The header files such as "parser.hh", "location.hh", etc. used a constant
2875 name for preprocessor guards, for instance:
2877 #ifndef BISON_LOCATION_HH
2878 # define BISON_LOCATION_HH
2880 #endif // !BISON_LOCATION_HH
2882 The inclusion guard is now computed from "PREFIX/FILE-NAME", where lower
2883 case characters are converted to upper case, and series of
2884 non-alphanumerical characters are converted to an underscore.
2886 With "bison -o lang++/parser.cc", "location.hh" would now include:
2888 #ifndef YY_LANG_LOCATION_HH
2889 # define YY_LANG_LOCATION_HH
2891 #endif // !YY_LANG_LOCATION_HH
2895 The position and location constructors (and their initialize methods)
2896 accept new arguments for line and column. Several issues in the
2897 documentation were fixed.
2899 ** liby is no longer asking for "rpl_fprintf" on some platforms.
2901 ** Changes in the manual:
2903 *** %printer is documented
2905 The "%printer" directive, supported since at least Bison 1.50, is finally
2906 documented. The "mfcalc" example is extended to demonstrate it.
2908 For consistency with the C skeletons, the C++ parsers now also support
2909 "yyoutput" (as an alias to "debug_stream ()").
2911 *** Several improvements have been made:
2913 The layout for grammar excerpts was changed to a more compact scheme.
2914 Named references are motivated. The description of the automaton
2915 description file (*.output) is updated to the current format. Incorrect
2916 index entries were fixed. Some other errors were fixed.
2920 *** Conflicting prototypes with recent/modified Flex.
2922 Fixed build problems with the current, unreleased, version of Flex, and
2923 some modified versions of 2.5.35, which have modified function prototypes.
2925 *** Warnings during the build procedure have been eliminated.
2927 *** Several portability problems in the test suite have been fixed:
2929 This includes warnings with some compilers, unexpected behavior of tools
2930 such as diff, warning messages from the test suite itself, etc.
2932 *** The install-pdf target works properly:
2934 Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
2935 halts in the middle of its course.
2938 * Noteworthy changes in release 2.5 (2011-05-14)
2940 ** Grammar symbol names can now contain non-initial dashes:
2942 Consistently with directives (such as %error-verbose) and with
2943 %define variables (e.g. push-pull), grammar symbol names may contain
2944 dashes in any position except the beginning. This is a GNU
2945 extension over POSIX Yacc. Thus, use of this extension is reported
2946 by -Wyacc and rejected in Yacc mode (--yacc).
2948 ** Named references:
2950 Historically, Yacc and Bison have supported positional references
2951 ($n, $$) to allow access to symbol values from inside of semantic
2954 Starting from this version, Bison can also accept named references.
2955 When no ambiguity is possible, original symbol names may be used
2956 as named references:
2958 if_stmt : "if" cond_expr "then" then_stmt ';'
2959 { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }
2961 In the more common case, explicit names may be declared:
2963 stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
2964 { $res = mk_if_stmt($cond, $then, $else); }
2966 Location information is also accessible using @name syntax. When
2967 accessing symbol names containing dots or dashes, explicit bracketing
2968 ($[sym.1]) must be used.
2970 These features are experimental in this version. More user feedback
2971 will help to stabilize them.
2972 Contributed by Alex Rozenman.
2974 ** IELR(1) and canonical LR(1):
2976 IELR(1) is a minimal LR(1) parser table generation algorithm. That
2977 is, given any context-free grammar, IELR(1) generates parser tables
2978 with the full language-recognition power of canonical LR(1) but with
2979 nearly the same number of parser states as LALR(1). This reduction
2980 in parser states is often an order of magnitude. More importantly,
2981 because canonical LR(1)'s extra parser states may contain duplicate
2982 conflicts in the case of non-LR(1) grammars, the number of conflicts
2983 for IELR(1) is often an order of magnitude less as well. This can
2984 significantly reduce the complexity of developing of a grammar.
2986 Bison can now generate IELR(1) and canonical LR(1) parser tables in
2987 place of its traditional LALR(1) parser tables, which remain the
2988 default. You can specify the type of parser tables in the grammar
2989 file with these directives:
2991 %define lr.type lalr
2992 %define lr.type ielr
2993 %define lr.type canonical-lr
2995 The default-reduction optimization in the parser tables can also be
2996 adjusted using "%define lr.default-reductions". For details on both
2997 of these features, see the new section "Tuning LR" in the Bison
3000 These features are experimental. More user feedback will help to
3003 ** LAC (Lookahead Correction) for syntax error handling
3005 Contributed by Joel E. Denny.
3007 Canonical LR, IELR, and LALR can suffer from a couple of problems
3008 upon encountering a syntax error. First, the parser might perform
3009 additional parser stack reductions before discovering the syntax
3010 error. Such reductions can perform user semantic actions that are
3011 unexpected because they are based on an invalid token, and they
3012 cause error recovery to begin in a different syntactic context than
3013 the one in which the invalid token was encountered. Second, when
3014 verbose error messages are enabled (with %error-verbose or the
3015 obsolete "#define YYERROR_VERBOSE"), the expected token list in the
3016 syntax error message can both contain invalid tokens and omit valid
3019 The culprits for the above problems are %nonassoc, default
3020 reductions in inconsistent states, and parser state merging. Thus,
3021 IELR and LALR suffer the most. Canonical LR can suffer only if
3022 %nonassoc is used or if default reductions are enabled for
3023 inconsistent states.
3025 LAC is a new mechanism within the parsing algorithm that solves
3026 these problems for canonical LR, IELR, and LALR without sacrificing
3027 %nonassoc, default reductions, or state merging. When LAC is in
3028 use, canonical LR and IELR behave almost exactly the same for both
3029 syntactically acceptable and syntactically unacceptable input.
3030 While LALR still does not support the full language-recognition
3031 power of canonical LR and IELR, LAC at least enables LALR's syntax
3032 error handling to correctly reflect LALR's language-recognition
3035 Currently, LAC is only supported for deterministic parsers in C.
3036 You can enable LAC with the following directive:
3038 %define parse.lac full
3040 See the new section "LAC" in the Bison manual for additional
3041 details including a few caveats.
3043 LAC is an experimental feature. More user feedback will help to
3046 ** %define improvements:
3048 *** Can now be invoked via the command line:
3050 Each of these command-line options
3053 --define=NAME[=VALUE]
3056 --force-define=NAME[=VALUE]
3058 is equivalent to this grammar file declaration
3060 %define NAME ["VALUE"]
3062 except that the manner in which Bison processes multiple definitions
3063 for the same NAME differs. Most importantly, -F and --force-define
3064 quietly override %define, but -D and --define do not. For further
3065 details, see the section "Bison Options" in the Bison manual.
3067 *** Variables renamed:
3069 The following %define variables
3072 lr.keep_unreachable_states
3074 have been renamed to
3077 lr.keep-unreachable-states
3079 The old names are now deprecated but will be maintained indefinitely
3080 for backward compatibility.
3082 *** Values no longer need to be quoted in the grammar file:
3084 If a %define value is an identifier, it no longer needs to be placed
3085 within quotations marks. For example,
3087 %define api.push-pull "push"
3091 %define api.push-pull push
3093 *** Unrecognized variables are now errors not warnings.
3095 *** Multiple invocations for any variable is now an error not a warning.
3097 ** Unrecognized %code qualifiers are now errors not warnings.
3099 ** Character literals not of length one:
3101 Previously, Bison quietly converted all character literals to length
3102 one. For example, without warning, Bison interpreted the operators in
3103 the following grammar to be the same token:
3109 Bison now warns when a character literal is not of length one. In
3110 some future release, Bison will start reporting an error instead.
3112 ** Destructor calls fixed for lookaheads altered in semantic actions:
3114 Previously for deterministic parsers in C, if a user semantic action
3115 altered yychar, the parser in some cases used the old yychar value to
3116 determine which destructor to call for the lookahead upon a syntax
3117 error or upon parser return. This bug has been fixed.
3119 ** C++ parsers use YYRHSLOC:
3121 Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
3122 macro and use it in the default YYLLOC_DEFAULT. You are encouraged
3123 to use it. If, for instance, your location structure has "first"
3124 and "last" members, instead of
3126 # define YYLLOC_DEFAULT(Current, Rhs, N) \
3130 (Current).first = (Rhs)[1].location.first; \
3131 (Current).last = (Rhs)[N].location.last; \
3135 (Current).first = (Current).last = (Rhs)[0].location.last; \
3141 # define YYLLOC_DEFAULT(Current, Rhs, N) \
3145 (Current).first = YYRHSLOC (Rhs, 1).first; \
3146 (Current).last = YYRHSLOC (Rhs, N).last; \
3150 (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last; \
3154 ** YYLLOC_DEFAULT in C++:
3156 The default implementation of YYLLOC_DEFAULT used to be issued in
3157 the header file. It is now output in the implementation file, after
3158 the user %code sections so that its #ifndef guard does not try to
3159 override the user's YYLLOC_DEFAULT if provided.
3161 ** YYFAIL now produces warnings and Java parsers no longer implement it:
3163 YYFAIL has existed for many years as an undocumented feature of
3164 deterministic parsers in C generated by Bison. More recently, it was
3165 a documented feature of Bison's experimental Java parsers. As
3166 promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
3167 semantic action now produces a deprecation warning, and Java parsers
3168 no longer implement YYFAIL at all. For further details, including a
3169 discussion of how to suppress C preprocessor warnings about YYFAIL
3170 being unused, see the Bison 2.4.2 NEWS entry.
3172 ** Temporary hack for adding a semicolon to the user action:
3174 Previously, Bison appended a semicolon to every user action for
3175 reductions when the output language defaulted to C (specifically, when
3176 neither %yacc, %language, %skeleton, or equivalent command-line
3177 options were specified). This allowed actions such as
3179 exp: exp "+" exp { $$ = $1 + $3 };
3183 exp: exp "+" exp { $$ = $1 + $3; };
3185 As a first step in removing this misfeature, Bison now issues a
3186 warning when it appends a semicolon. Moreover, in cases where Bison
3187 cannot easily determine whether a semicolon is needed (for example, an
3188 action ending with a cpp directive or a braced compound initializer),
3189 it no longer appends one. Thus, the C compiler might now complain
3190 about a missing semicolon where it did not before. Future releases of
3191 Bison will cease to append semicolons entirely.
3193 ** Verbose syntax error message fixes:
3195 When %error-verbose or the obsolete "#define YYERROR_VERBOSE" is
3196 specified, syntax error messages produced by the generated parser
3197 include the unexpected token as well as a list of expected tokens.
3198 The effect of %nonassoc on these verbose messages has been corrected
3199 in two ways, but a more complete fix requires LAC, described above:
3201 *** When %nonassoc is used, there can exist parser states that accept no
3202 tokens, and so the parser does not always require a lookahead token
3203 in order to detect a syntax error. Because no unexpected token or
3204 expected tokens can then be reported, the verbose syntax error
3205 message described above is suppressed, and the parser instead
3206 reports the simpler message, "syntax error". Previously, this
3207 suppression was sometimes erroneously triggered by %nonassoc when a
3208 lookahead was actually required. Now verbose messages are
3209 suppressed only when all previous lookaheads have already been
3210 shifted or discarded.
3212 *** Previously, the list of expected tokens erroneously included tokens
3213 that would actually induce a syntax error because conflicts for them
3214 were resolved with %nonassoc in the current parser state. Such
3215 tokens are now properly omitted from the list.
3217 *** Expected token lists are still often wrong due to state merging
3218 (from LALR or IELR) and default reductions, which can both add
3219 invalid tokens and subtract valid tokens. Canonical LR almost
3220 completely fixes this problem by eliminating state merging and
3221 default reductions. However, there is one minor problem left even
3222 when using canonical LR and even after the fixes above. That is,
3223 if the resolution of a conflict with %nonassoc appears in a later
3224 parser state than the one at which some syntax error is
3225 discovered, the conflicted token is still erroneously included in
3226 the expected token list. Bison's new LAC implementation,
3227 described above, eliminates this problem and the need for
3228 canonical LR. However, LAC is still experimental and is disabled
3231 ** Java skeleton fixes:
3233 *** A location handling bug has been fixed.
3235 *** The top element of each of the value stack and location stack is now
3236 cleared when popped so that it can be garbage collected.
3238 *** Parser traces now print the top element of the stack.
3240 ** -W/--warnings fixes:
3242 *** Bison now properly recognizes the "no-" versions of categories:
3244 For example, given the following command line, Bison now enables all
3245 warnings except warnings for incompatibilities with POSIX Yacc:
3247 bison -Wall,no-yacc gram.y
3249 *** Bison now treats S/R and R/R conflicts like other warnings:
3251 Previously, conflict reports were independent of Bison's normal
3252 warning system. Now, Bison recognizes the warning categories
3253 "conflicts-sr" and "conflicts-rr". This change has important
3254 consequences for the -W and --warnings command-line options. For
3257 bison -Wno-conflicts-sr gram.y # S/R conflicts not reported
3258 bison -Wno-conflicts-rr gram.y # R/R conflicts not reported
3259 bison -Wnone gram.y # no conflicts are reported
3260 bison -Werror gram.y # any conflict is an error
3262 However, as before, if the %expect or %expect-rr directive is
3263 specified, an unexpected number of conflicts is an error, and an
3264 expected number of conflicts is not reported, so -W and --warning
3265 then have no effect on the conflict report.
3267 *** The "none" category no longer disables a preceding "error":
3269 For example, for the following command line, Bison now reports
3270 errors instead of warnings for incompatibilities with POSIX Yacc:
3272 bison -Werror,none,yacc gram.y
3274 *** The "none" category now disables all Bison warnings:
3276 Previously, the "none" category disabled only Bison warnings for
3277 which there existed a specific -W/--warning category. However,
3278 given the following command line, Bison is now guaranteed to
3279 suppress all warnings:
3283 ** Precedence directives can now assign token number 0:
3285 Since Bison 2.3b, which restored the ability of precedence
3286 directives to assign token numbers, doing so for token number 0 has
3287 produced an assertion failure. For example:
3291 This bug has been fixed.
3294 * Noteworthy changes in release 2.4.3 (2010-08-05)
3296 ** Bison now obeys -Werror and --warnings=error for warnings about
3297 grammar rules that are useless in the parser due to conflicts.
3299 ** Problems with spawning M4 on at least FreeBSD 8 and FreeBSD 9 have
3302 ** Failures in the test suite for GCC 4.5 have been fixed.
3304 ** Failures in the test suite for some versions of Sun Studio C++ have
3307 ** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
3308 warnings about undefined %prec identifiers will not be converted to
3309 errors in Bison 2.5. They will remain warnings, which should be
3310 sufficient for POSIX while avoiding backward compatibility issues.
3312 ** Minor documentation fixes.
3315 * Noteworthy changes in release 2.4.2 (2010-03-20)
3317 ** Some portability problems that resulted in failures and livelocks
3318 in the test suite on some versions of at least Solaris, AIX, HP-UX,
3319 RHEL4, and Tru64 have been addressed. As a result, fatal Bison
3320 errors should no longer cause M4 to report a broken pipe on the
3323 ** "%prec IDENTIFIER" requires IDENTIFIER to be defined separately.
3325 POSIX specifies that an error be reported for any identifier that does
3326 not appear on the LHS of a grammar rule and that is not defined by
3327 %token, %left, %right, or %nonassoc. Bison 2.3b and later lost this
3328 error report for the case when an identifier appears only after a
3329 %prec directive. It is now restored. However, for backward
3330 compatibility with recent Bison releases, it is only a warning for
3331 now. In Bison 2.5 and later, it will return to being an error.
3332 [Between the 2.4.2 and 2.4.3 releases, it was decided that this
3333 warning will not be converted to an error in Bison 2.5.]
3335 ** Detection of GNU M4 1.4.6 or newer during configure is improved.
3337 ** Warnings from gcc's -Wundef option about undefined YYENABLE_NLS,
3338 YYLTYPE_IS_TRIVIAL, and __STRICT_ANSI__ in C/C++ parsers are now
3341 ** %code is now a permanent feature.
3343 A traditional Yacc prologue directive is written in the form:
3347 To provide a more flexible alternative, Bison 2.3b introduced the
3348 %code directive with the following forms for C/C++:
3351 %code requires {CODE}
3352 %code provides {CODE}
3355 These forms are now considered permanent features of Bison. See the
3356 %code entries in the section "Bison Declaration Summary" in the Bison
3357 manual for a summary of their functionality. See the section
3358 "Prologue Alternatives" for a detailed discussion including the
3359 advantages of %code over the traditional Yacc prologue directive.
3361 Bison's Java feature as a whole including its current usage of %code
3362 is still considered experimental.
3364 ** YYFAIL is deprecated and will eventually be removed.
3366 YYFAIL has existed for many years as an undocumented feature of
3367 deterministic parsers in C generated by Bison. Previously, it was
3368 documented for Bison's experimental Java parsers. YYFAIL is no longer
3369 documented for Java parsers and is formally deprecated in both cases.
3370 Users are strongly encouraged to migrate to YYERROR, which is
3373 Like YYERROR, you can invoke YYFAIL from a semantic action in order to
3374 induce a syntax error. The most obvious difference from YYERROR is
3375 that YYFAIL will automatically invoke yyerror to report the syntax
3376 error so that you don't have to. However, there are several other
3377 subtle differences between YYERROR and YYFAIL, and YYFAIL suffers from
3378 inherent flaws when %error-verbose or "#define YYERROR_VERBOSE" is
3379 used. For a more detailed discussion, see:
3381 http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html
3383 The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but
3384 deterministic parsers in C will continue to implement it. However,
3385 because YYFAIL is already flawed, it seems futile to try to make new
3386 Bison features compatible with it. Thus, during parser generation,
3387 Bison 2.5 will produce a warning whenever it discovers YYFAIL in a
3388 rule action. In a later release, YYFAIL will be disabled for
3389 %error-verbose and "#define YYERROR_VERBOSE". Eventually, YYFAIL will
3390 be removed altogether.
3392 There exists at least one case where Bison 2.5's YYFAIL warning will
3393 be a false positive. Some projects add phony uses of YYFAIL and other
3394 Bison-defined macros for the sole purpose of suppressing C
3395 preprocessor warnings (from GCC cpp's -Wunused-macros, for example).
3396 To avoid Bison's future warning, such YYFAIL uses can be moved to the
3397 epilogue (that is, after the second "%%") in the Bison input file. In
3398 this release (2.4.2), Bison already generates its own code to suppress
3399 C preprocessor warnings for YYFAIL, so projects can remove their own
3400 phony uses of YYFAIL if compatibility with Bison releases prior to
3401 2.4.2 is not necessary.
3403 ** Internationalization.
3405 Fix a regression introduced in Bison 2.4: Under some circumstances,
3406 message translations were not installed although supported by the
3410 * Noteworthy changes in release 2.4.1 (2008-12-11)
3412 ** In the GLR defines file, unexpanded M4 macros in the yylval and yylloc
3413 declarations have been fixed.
3415 ** Temporary hack for adding a semicolon to the user action.
3417 Bison used to prepend a trailing semicolon at the end of the user
3418 action for reductions. This allowed actions such as
3420 exp: exp "+" exp { $$ = $1 + $3 };
3424 exp: exp "+" exp { $$ = $1 + $3; };
3426 Some grammars still depend on this "feature". Bison 2.4.1 restores
3427 the previous behavior in the case of C output (specifically, when
3428 neither %language or %skeleton or equivalent command-line options
3429 are used) to leave more time for grammars depending on the old
3430 behavior to be adjusted. Future releases of Bison will disable this
3433 ** A few minor improvements to the Bison manual.
3436 * Noteworthy changes in release 2.4 (2008-11-02)
3438 ** %language is an experimental feature.
3440 We first introduced this feature in test release 2.3b as a cleaner
3441 alternative to %skeleton. Since then, we have discussed the possibility of
3442 modifying its effect on Bison's output file names. Thus, in this release,
3443 we consider %language to be an experimental feature that will likely evolve
3446 ** Forward compatibility with GNU M4 has been improved.
3448 ** Several bugs in the C++ skeleton and the experimental Java skeleton have been
3452 * Noteworthy changes in release 2.3b (2008-05-27)
3454 ** The quotes around NAME that used to be required in the following directive
3457 %define NAME "VALUE"
3459 ** The directive "%pure-parser" is now deprecated in favor of:
3463 which has the same effect except that Bison is more careful to warn about
3464 unreasonable usage in the latter case.
3468 Bison can now generate an LALR(1) parser in C with a push interface. That
3469 is, instead of invoking "yyparse", which pulls tokens from "yylex", you can
3470 push one token at a time to the parser using "yypush_parse", which will
3471 return to the caller after processing each token. By default, the push
3472 interface is disabled. Either of the following directives will enable it:
3474 %define api.push_pull "push" // Just push; does not require yylex.
3475 %define api.push_pull "both" // Push and pull; requires yylex.
3477 See the new section "A Push Parser" in the Bison manual for details.
3479 The current push parsing interface is experimental and may evolve. More user
3480 feedback will help to stabilize it.
3482 ** The -g and --graph options now output graphs in Graphviz DOT format,
3483 not VCG format. Like --graph, -g now also takes an optional FILE argument
3484 and thus cannot be bundled with other short options.
3488 Bison can now generate an LALR(1) parser in Java. The skeleton is
3489 "data/lalr1.java". Consider using the new %language directive instead of
3490 %skeleton to select it.
3492 See the new section "Java Parsers" in the Bison manual for details.
3494 The current Java interface is experimental and may evolve. More user
3495 feedback will help to stabilize it.
3496 Contributed by Paolo Bonzini.
3500 This new directive specifies the programming language of the generated
3501 parser, which can be C (the default), C++, or Java. Besides the skeleton
3502 that Bison uses, the directive affects the names of the generated files if
3503 the grammar file's name ends in ".y".
3505 ** XML Automaton Report
3507 Bison can now generate an XML report of the LALR(1) automaton using the new
3508 "--xml" option. The current XML schema is experimental and may evolve. More
3509 user feedback will help to stabilize it.
3510 Contributed by Wojciech Polak.
3512 ** The grammar file may now specify the name of the parser header file using
3513 %defines. For example:
3517 ** When reporting useless rules, useless nonterminals, and unused terminals,
3518 Bison now employs the terms "useless in grammar" instead of "useless",
3519 "useless in parser" instead of "never reduced", and "unused in grammar"
3520 instead of "unused".
3522 ** Unreachable State Removal
3524 Previously, Bison sometimes generated parser tables containing unreachable
3525 states. A state can become unreachable during conflict resolution if Bison
3526 disables a shift action leading to it from a predecessor state. Bison now:
3528 1. Removes unreachable states.
3530 2. Does not report any conflicts that appeared in unreachable states.
3531 WARNING: As a result, you may need to update %expect and %expect-rr
3532 directives in existing grammar files.
3534 3. For any rule used only in such states, Bison now reports the rule as
3535 "useless in parser due to conflicts".
3537 This feature can be disabled with the following directive:
3539 %define lr.keep_unreachable_states
3541 See the %define entry in the "Bison Declaration Summary" in the Bison manual
3542 for further discussion.
3544 ** Lookahead Set Correction in the ".output" Report
3546 When instructed to generate a ".output" file including lookahead sets
3547 (using "--report=lookahead", for example), Bison now prints each reduction's
3548 lookahead set only next to the associated state's one item that (1) is
3549 associated with the same rule as the reduction and (2) has its dot at the end
3550 of its RHS. Previously, Bison also erroneously printed the lookahead set
3551 next to all of the state's other items associated with the same rule. This
3552 bug affected only the ".output" file and not the generated parser source
3555 ** --report-file=FILE is a new option to override the default ".output" file
3558 ** The "=" that used to be required in the following directives is now
3561 %file-prefix "parser"
3565 ** An Alternative to "%{...%}" -- "%code QUALIFIER {CODE}"
3567 Bison 2.3a provided a new set of directives as a more flexible alternative to
3568 the traditional Yacc prologue blocks. Those have now been consolidated into
3569 a single %code directive with an optional qualifier field, which identifies
3570 the purpose of the code and thus the location(s) where Bison should generate
3573 1. "%code {CODE}" replaces "%after-header {CODE}"
3574 2. "%code requires {CODE}" replaces "%start-header {CODE}"
3575 3. "%code provides {CODE}" replaces "%end-header {CODE}"
3576 4. "%code top {CODE}" replaces "%before-header {CODE}"
3578 See the %code entries in section "Bison Declaration Summary" in the Bison
3579 manual for a summary of the new functionality. See the new section "Prologue
3580 Alternatives" for a detailed discussion including the advantages of %code
3581 over the traditional Yacc prologues.
3583 The prologue alternatives are experimental. More user feedback will help to
3584 determine whether they should become permanent features.
3586 ** Revised warning: unset or unused midrule values
3588 Since Bison 2.2, Bison has warned about midrule values that are set but not
3589 used within any of the actions of the parent rule. For example, Bison warns
3592 exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };
3594 Now, Bison also warns about midrule values that are used but not set. For
3595 example, Bison warns about unset $$ in the midrule action in:
3597 exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };
3599 However, Bison now disables both of these warnings by default since they
3600 sometimes prove to be false alarms in existing grammars employing the Yacc
3601 constructs $0 or $-N (where N is some positive integer).
3603 To enable these warnings, specify the option "--warnings=midrule-values" or
3604 "-W", which is a synonym for "--warnings=all".
3606 ** Default %destructor or %printer with "<*>" or "<>"
3608 Bison now recognizes two separate kinds of default %destructor's and
3611 1. Place "<*>" in a %destructor/%printer symbol list to define a default
3612 %destructor/%printer for all grammar symbols for which you have formally
3613 declared semantic type tags.
3615 2. Place "<>" in a %destructor/%printer symbol list to define a default
3616 %destructor/%printer for all grammar symbols without declared semantic
3619 Bison no longer supports the "%symbol-default" notation from Bison 2.3a.
3620 "<*>" and "<>" combined achieve the same effect with one exception: Bison no
3621 longer applies any %destructor to a midrule value if that midrule value is
3622 not actually ever referenced using either $$ or $n in a semantic action.
3624 The default %destructor's and %printer's are experimental. More user
3625 feedback will help to determine whether they should become permanent
3628 See the section "Freeing Discarded Symbols" in the Bison manual for further
3631 ** %left, %right, and %nonassoc can now declare token numbers. This is required
3632 by POSIX. However, see the end of section "Operator Precedence" in the Bison
3633 manual for a caveat concerning the treatment of literal strings.
3635 ** The nonfunctional --no-parser, -n, and %no-parser options have been
3636 completely removed from Bison.
3639 * Noteworthy changes in release 2.3a (2006-09-13)
3641 ** Instead of %union, you can define and use your own union type
3642 YYSTYPE if your grammar contains at least one <type> tag.
3643 Your YYSTYPE need not be a macro; it can be a typedef.
3644 This change is for compatibility with other Yacc implementations,
3645 and is required by POSIX.
3647 ** Locations columns and lines start at 1.
3648 In accordance with the GNU Coding Standards and Emacs.
3650 ** You may now declare per-type and default %destructor's and %printer's:
3654 %union { char *string; }
3655 %token <string> STRING1
3656 %token <string> STRING2
3657 %type <string> string1
3658 %type <string> string2
3659 %union { char character; }
3660 %token <character> CHR
3661 %type <character> chr
3662 %destructor { free ($$); } %symbol-default
3663 %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
3664 %destructor { } <character>
3666 guarantees that, when the parser discards any user-defined symbol that has a
3667 semantic type tag other than "<character>", it passes its semantic value to
3668 "free". However, when the parser discards a "STRING1" or a "string1", it
3669 also prints its line number to "stdout". It performs only the second
3670 "%destructor" in this case, so it invokes "free" only once.
3672 [Although we failed to mention this here in the 2.3a release, the default
3673 %destructor's and %printer's were experimental, and they were rewritten in
3676 ** Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with "-y",
3677 "--yacc", or "%yacc"), Bison no longer generates #define statements for
3678 associating token numbers with token names. Removing the #define statements
3679 helps to sanitize the global namespace during preprocessing, but POSIX Yacc
3680 requires them. Bison still generates an enum for token names in all cases.
3682 ** Handling of traditional Yacc prologue blocks is now more consistent but
3683 potentially incompatible with previous releases of Bison.
3685 As before, you declare prologue blocks in your grammar file with the
3686 "%{ ... %}" syntax. To generate the pre-prologue, Bison concatenates all
3687 prologue blocks that you've declared before the first %union. To generate
3688 the post-prologue, Bison concatenates all prologue blocks that you've
3689 declared after the first %union.
3691 Previous releases of Bison inserted the pre-prologue into both the header
3692 file and the code file in all cases except for LALR(1) parsers in C. In the
3693 latter case, Bison inserted it only into the code file. For parsers in C++,
3694 the point of insertion was before any token definitions (which associate
3695 token numbers with names). For parsers in C, the point of insertion was
3696 after the token definitions.
3698 Now, Bison never inserts the pre-prologue into the header file. In the code
3699 file, it always inserts it before the token definitions.
3701 ** Bison now provides a more flexible alternative to the traditional Yacc
3702 prologue blocks: %before-header, %start-header, %end-header, and
3705 For example, the following declaration order in the grammar file reflects the
3706 order in which Bison will output these code blocks. However, you are free to
3707 declare these code blocks in your grammar file in whatever order is most
3711 /* Bison treats this block like a pre-prologue block: it inserts it into
3712 * the code file before the contents of the header file. It does *not*
3713 * insert it into the header file. This is a good place to put
3714 * #include's that you want at the top of your code file. A common
3715 * example is '#include "system.h"'. */
3718 /* Bison inserts this block into both the header file and the code file.
3719 * In both files, the point of insertion is before any Bison-generated
3720 * token, semantic type, location type, and class definitions. This is a
3721 * good place to define %union dependencies, for example. */
3724 /* Unlike the traditional Yacc prologue blocks, the output order for the
3725 * new %*-header blocks is not affected by their declaration position
3726 * relative to any %union in the grammar file. */
3729 /* Bison inserts this block into both the header file and the code file.
3730 * In both files, the point of insertion is after the Bison-generated
3731 * definitions. This is a good place to declare or define public
3732 * functions or data structures that depend on the Bison-generated
3736 /* Bison treats this block like a post-prologue block: it inserts it into
3737 * the code file after the contents of the header file. It does *not*
3738 * insert it into the header file. This is a good place to declare or
3739 * define internal functions or data structures that depend on the
3740 * Bison-generated definitions. */
3743 If you have multiple occurrences of any one of the above declarations, Bison
3744 will concatenate the contents in declaration order.
3746 [Although we failed to mention this here in the 2.3a release, the prologue
3747 alternatives were experimental, and they were rewritten in future versions.]
3749 ** The option "--report=look-ahead" has been changed to "--report=lookahead".
3750 The old spelling still works, but is not documented and may be removed
3751 in a future release.
3754 * Noteworthy changes in release 2.3 (2006-06-05)
3756 ** GLR grammars should now use "YYRECOVERING ()" instead of "YYRECOVERING",
3757 for compatibility with LALR(1) grammars.
3759 ** It is now documented that any definition of YYSTYPE or YYLTYPE should
3760 be to a type name that does not contain parentheses or brackets.
3763 * Noteworthy changes in release 2.2 (2006-05-19)
3765 ** The distribution terms for all Bison-generated parsers now permit
3766 using the parsers in nonfree programs. Previously, this permission
3767 was granted only for Bison-generated LALR(1) parsers in C.
3769 ** %name-prefix changes the namespace name in C++ outputs.
3771 ** The C++ parsers export their token_type.
3773 ** Bison now allows multiple %union declarations, and concatenates
3774 their contents together.
3776 ** New warning: unused values
3777 Right-hand side symbols whose values are not used are reported,
3778 if the symbols have destructors. For instance:
3780 exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
3784 will trigger a warning about $$ and $5 in the first rule, and $3 in
3785 the second ($1 is copied to $$ by the default rule). This example
3786 most likely contains three errors, and could be rewritten as:
3788 exp: exp "?" exp ":" exp
3789 { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
3791 { $$ = $1 ? $1 : $3; if ($1) free ($3); }
3794 However, if the original actions were really intended, memory leaks
3795 and all, the warnings can be suppressed by letting Bison believe the
3796 values are used, e.g.:
3798 exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
3799 | exp "+" exp { $$ = $1; (void) $3; }
3802 If there are midrule actions, the warning is issued if no action
3803 uses it. The following triggers no warning: $1 and $3 are used.
3805 exp: exp { push ($1); } '+' exp { push ($3); sum (); };
3807 The warning is intended to help catching lost values and memory leaks.
3808 If a value is ignored, its associated memory typically is not reclaimed.
3810 ** %destructor vs. YYABORT, YYACCEPT, and YYERROR.
3811 Destructors are now called when user code invokes YYABORT, YYACCEPT,
3812 and YYERROR, for all objects on the stack, other than objects
3813 corresponding to the right-hand side of the current rule.
3815 ** %expect, %expect-rr
3816 Incorrect numbers of expected conflicts are now actual errors,
3817 instead of warnings.
3819 ** GLR, YACC parsers.
3820 The %parse-params are available in the destructors (and the
3821 experimental printers) as per the documentation.
3823 ** Bison now warns if it finds a stray "$" or "@" in an action.
3825 ** %require "VERSION"
3826 This specifies that the grammar file depends on features implemented
3827 in Bison version VERSION or higher.
3829 ** lalr1.cc: The token and value types are now class members.
3830 The tokens were defined as free form enums and cpp macros. YYSTYPE
3831 was defined as a free form union. They are now class members:
3832 tokens are enumerations of the "yy::parser::token" struct, and the
3833 semantic values have the "yy::parser::semantic_type" type.
3835 If you do not want or can update to this scheme, the directive
3836 '%define "global_tokens_and_yystype" "1"' triggers the global
3837 definition of tokens and YYSTYPE. This change is suitable both
3838 for previous releases of Bison, and this one.
3840 If you wish to update, then make sure older version of Bison will
3841 fail using '%require "2.2"'.
3843 ** DJGPP support added.
3846 * Noteworthy changes in release 2.1 (2005-09-16)
3848 ** The C++ lalr1.cc skeleton supports %lex-param.
3850 ** Bison-generated parsers now support the translation of diagnostics like
3851 "syntax error" into languages other than English. The default
3852 language is still English. For details, please see the new
3853 Internationalization section of the Bison manual. Software
3854 distributors should also see the new PACKAGING file. Thanks to
3855 Bruno Haible for this new feature.
3857 ** Wording in the Bison-generated parsers has been changed slightly to
3858 simplify translation. In particular, the message "memory exhausted"
3859 has replaced "parser stack overflow", as the old message was not
3860 always accurate for modern Bison-generated parsers.
3862 ** Destructors are now called when the parser aborts, for all symbols left
3863 behind on the stack. Also, the start symbol is now destroyed after a
3864 successful parse. In both cases, the behavior was formerly inconsistent.
3866 ** When generating verbose diagnostics, Bison-generated parsers no longer
3867 quote the literal strings associated with tokens. For example, for
3868 a syntax error associated with '%token NUM "number"' they might
3869 print 'syntax error, unexpected number' instead of 'syntax error,
3870 unexpected "number"'.
3873 * Noteworthy changes in release 2.0 (2004-12-25)
3875 ** Possibly-incompatible changes
3877 - Bison-generated parsers no longer default to using the alloca function
3878 (when available) to extend the parser stack, due to widespread
3879 problems in unchecked stack-overflow detection. You can "#define
3880 YYSTACK_USE_ALLOCA 1" to require the use of alloca, but please read
3881 the manual to determine safe values for YYMAXDEPTH in that case.
3883 - Error token location.
3884 During error recovery, the location of the syntax error is updated
3885 to cover the whole sequence covered by the error token: it includes
3886 the shifted symbols thrown away during the first part of the error
3887 recovery, and the lookahead rejected during the second part.
3889 - Semicolon changes:
3890 . Stray semicolons are no longer allowed at the start of a grammar.
3891 . Semicolons are now required after in-grammar declarations.
3893 - Unescaped newlines are no longer allowed in character constants or
3894 string literals. They were never portable, and GCC 3.4.0 has
3895 dropped support for them. Better diagnostics are now generated if
3896 forget a closing quote.
3898 - NUL bytes are no longer allowed in Bison string literals, unfortunately.
3902 - GLR grammars now support locations.
3904 - New directive: %initial-action.
3905 This directive allows the user to run arbitrary code (including
3906 initializing @$) from yyparse before parsing starts.
3908 - A new directive "%expect-rr N" specifies the expected number of
3909 reduce/reduce conflicts in GLR parsers.
3911 - %token numbers can now be hexadecimal integers, e.g., "%token FOO 0x12d".
3912 This is a GNU extension.
3914 - The option "--report=lookahead" was changed to "--report=look-ahead".
3915 [However, this was changed back after 2.3.]
3917 - Experimental %destructor support has been added to lalr1.cc.
3919 - New configure option --disable-yacc, to disable installation of the
3920 yacc command and -ly library introduced in 1.875 for POSIX conformance.
3924 - For now, %expect-count violations are now just warnings, not errors.
3925 This is for compatibility with Bison 1.75 and earlier (when there are
3926 reduce/reduce conflicts) and with Bison 1.30 and earlier (when there
3927 are too many or too few shift/reduce conflicts). However, in future
3928 versions of Bison we plan to improve the %expect machinery so that
3929 these violations will become errors again.
3931 - Within Bison itself, numbers (e.g., goto numbers) are no longer
3932 arbitrarily limited to 16-bit counts.
3934 - Semicolons are now allowed before "|" in grammar rules, as POSIX requires.
3937 * Noteworthy changes in release 1.875 (2003-01-01)
3939 ** The documentation license has been upgraded to version 1.2
3940 of the GNU Free Documentation License.
3942 ** syntax error processing
3944 - In Yacc-style parsers YYLLOC_DEFAULT is now used to compute error
3945 locations too. This fixes bugs in error-location computation.
3948 It is now possible to reclaim the memory associated to symbols
3949 discarded during error recovery. This feature is still experimental.
3952 This new directive is preferred over YYERROR_VERBOSE.
3954 - #defining yyerror to steal internal variables is discouraged.
3955 It is not guaranteed to work forever.
3957 ** POSIX conformance
3959 - Semicolons are once again optional at the end of grammar rules.
3960 This reverts to the behavior of Bison 1.33 and earlier, and improves
3961 compatibility with Yacc.
3963 - "parse error" -> "syntax error"
3964 Bison now uniformly uses the term "syntax error"; formerly, the code
3965 and manual sometimes used the term "parse error" instead. POSIX
3966 requires "syntax error" in diagnostics, and it was thought better to
3969 - The documentation now emphasizes that yylex and yyerror must be
3970 declared before use. C99 requires this.
3972 - Bison now parses C99 lexical constructs like UCNs and
3973 backslash-newline within C escape sequences, as POSIX 1003.1-2001 requires.
3975 - File names are properly escaped in C output. E.g., foo\bar.y is
3976 output as "foo\\bar.y".
3978 - Yacc command and library now available
3979 The Bison distribution now installs a "yacc" command, as POSIX requires.
3980 Also, Bison now installs a small library liby.a containing
3981 implementations of Yacc-compatible yyerror and main functions.
3982 This library is normally not useful, but POSIX requires it.
3984 - Type clashes now generate warnings, not errors.
3986 - If the user does not define YYSTYPE as a macro, Bison now declares it
3987 using typedef instead of defining it as a macro.
3988 For consistency, YYLTYPE is also declared instead of defined.
3990 ** Other compatibility issues
3992 - %union directives can now have a tag before the "{", e.g., the
3993 directive "%union foo {...}" now generates the C code
3994 "typedef union foo { ... } YYSTYPE;"; this is for Yacc compatibility.
3995 The default union tag is "YYSTYPE", for compatibility with Solaris 9 Yacc.
3996 For consistency, YYLTYPE's struct tag is now "YYLTYPE" not "yyltype".
3997 This is for compatibility with both Yacc and Bison 1.35.
3999 - ";" is output before the terminating "}" of an action, for
4000 compatibility with Bison 1.35.
4002 - Bison now uses a Yacc-style format for conflict reports, e.g.,
4003 "conflicts: 2 shift/reduce, 1 reduce/reduce".
4005 - "yystype" and "yyltype" are now obsolescent macros instead of being
4006 typedefs or tags; they are no longer documented and are planned to be
4007 withdrawn in a future release.
4012 Users of Bison have to decide how they handle the portability of the
4015 - "parsing stack overflow..." -> "parser stack overflow"
4016 GLR parsers now report "parser stack overflow" as per the Bison manual.
4018 ** %parse-param and %lex-param
4019 The macros YYPARSE_PARAM and YYLEX_PARAM provide a means to pass
4020 additional context to yyparse and yylex. They suffer from several
4023 - a single argument only can be added,
4024 - their types are weak (void *),
4025 - this context is not passed to ancillary functions such as yyerror,
4026 - only yacc.c parsers support them.
4028 The new %parse-param/%lex-param directives provide a more precise control.
4031 %parse-param {int *nastiness}
4032 %lex-param {int *nastiness}
4033 %parse-param {int *randomness}
4035 results in the following signatures:
4037 int yylex (int *nastiness);
4038 int yyparse (int *nastiness, int *randomness);
4040 or, if both %pure-parser and %locations are used:
4042 int yylex (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
4043 int yyparse (int *nastiness, int *randomness);
4045 ** Bison now warns if it detects conflicting outputs to the same file,
4046 e.g., it generates a warning for "bison -d -o foo.h foo.y" since
4047 that command outputs both code and header to foo.h.
4049 ** #line in output files
4050 - --no-line works properly.
4052 ** Bison can no longer be built by a K&R C compiler; it requires C89 or
4053 later to be built. This change originally took place a few versions
4054 ago, but nobody noticed until we recently asked someone to try
4055 building Bison with a K&R C compiler.
4058 * Noteworthy changes in release 1.75 (2002-10-14)
4060 ** Bison should now work on 64-bit hosts.
4062 ** Indonesian translation thanks to Tedi Heriyanto.
4065 Fix spurious parse errors.
4068 Some people redefine yyerror to steal yyparse' private variables.
4069 Reenable this trick until an official feature replaces it.
4072 In agreement with POSIX and with other Yaccs, leaving a default
4073 action is valid when $$ is untyped, and $1 typed:
4077 but the converse remains an error:
4081 ** Values of midrule actions
4084 foo: { ... } { $$ = $1; } ...
4086 was incorrectly rejected: $1 is defined in the second midrule
4087 action, and is equal to the $$ of the first midrule action.
4090 * Noteworthy changes in release 1.50 (2002-10-04)
4095 causes Bison to produce a Generalized LR (GLR) parser, capable of handling
4096 almost any context-free grammar, ambiguous or not. The new declarations
4097 %dprec and %merge on grammar rules allow parse-time resolution of
4098 ambiguities. Contributed by Paul Hilfinger.
4100 Unfortunately Bison 1.50 does not work properly on 64-bit hosts
4101 like the Alpha, so please stick to 32-bit hosts for now.
4104 When not in Yacc compatibility mode, when the output file was not
4105 specified, running "bison foo/bar.y" created "foo/bar.c". It
4106 now creates "bar.c".
4109 The undefined token was systematically mapped to 2 which prevented
4110 the use of 2 by the user. This is no longer the case.
4112 ** Unknown token numbers
4113 If yylex returned an out of range value, yyparse could die. This is
4117 According to POSIX, the error token must be 256.
4118 Bison extends this requirement by making it a preference: *if* the
4119 user specified that one of her tokens is numbered 256, then error
4120 will be mapped onto another number.
4122 ** Verbose error messages
4123 They no longer report "..., expecting error or..." for states where
4124 error recovery is possible.
4127 Defaults to "$end" instead of "$".
4129 ** Error recovery now conforms to documentation and to POSIX
4130 When a Bison-generated parser encounters a syntax error, it now pops
4131 the stack until it finds a state that allows shifting the error
4132 token. Formerly, it popped the stack until it found a state that
4133 allowed some non-error action other than a default reduction on the
4134 error token. The new behavior has long been the documented behavior,
4135 and has long been required by POSIX. For more details, please see
4136 Paul Eggert, "Reductions during Bison error handling" (2002-05-20)
4137 <http://lists.gnu.org/archive/html/bug-bison/2002-05/msg00038.html>.
4140 Popped tokens and nonterminals are now reported.
4143 Larger grammars are now supported (larger token numbers, larger grammar
4144 size (= sum of the LHS and RHS lengths), larger LALR tables).
4145 Formerly, many of these numbers ran afoul of 16-bit limits;
4146 now these limits are 32 bits on most hosts.
4148 ** Explicit initial rule
4149 Bison used to play hacks with the initial rule, which the user does
4150 not write. It is now explicit, and visible in the reports and
4154 Before, Bison reported the useless rules, but, although not used,
4155 included them in the parsers. They are now actually removed.
4157 ** Useless rules, useless nonterminals
4158 They are now reported, as a warning, with their locations.
4160 ** Rules never reduced
4161 Rules that can never be reduced because of conflicts are now
4164 ** Incorrect "Token not used"
4165 On a grammar such as
4167 %token useless useful
4169 exp: '0' %prec useful;
4171 where a token was used to set the precedence of the last rule,
4172 bison reported both "useful" and "useless" as useless tokens.
4174 ** Revert the C++ namespace changes introduced in 1.31
4175 as they caused too many portability hassles.
4177 ** Default locations
4178 By an accident of design, the default computation of @$ was
4179 performed after another default computation was performed: @$ = @1.
4180 The latter is now removed: YYLLOC_DEFAULT is fully responsible of
4181 the computation of @$.
4183 ** Token end-of-file
4184 The token end of file may be specified by the user, in which case,
4185 the user symbol is used in the reports, the graphs, and the verbose
4186 error messages instead of "$end", which remains being the default.
4190 %token MYEOF 0 "end of file"
4193 This old option, which has been broken for ages, is removed.
4196 Brazilian Portuguese, thanks to Alexandre Folle de Menezes.
4197 Croatian, thanks to Denis Lackovic.
4199 ** Incorrect token definitions
4202 bison used to output
4205 ** Token definitions as enums
4206 Tokens are output both as the traditional #define's, and, provided
4207 the compiler supports ANSI C or is a C++ compiler, as enums.
4208 This lets debuggers display names instead of integers.
4211 In addition to --verbose, bison supports --report=THINGS, which
4212 produces additional information:
4214 complete the core item sets with their closure
4215 - lookahead [changed to "look-ahead" in 1.875e through 2.3, but changed back]
4216 explicitly associate lookahead tokens to items
4218 describe shift/reduce conflicts solving.
4219 Bison used to systematically output this information on top of
4220 the report. Solved conflicts are now attached to their states.
4223 Previous versions don't complain when there is a type clash on
4224 the default action if the rule has a midrule action, such as in:
4232 ** GNU M4 is now required when using Bison.
4235 * Noteworthy changes in release 1.35 (2002-03-25)
4238 Some projects use Bison's C parser with C++ compilers, and define
4239 YYSTYPE as a class. The recent adjustment of C parsers for data
4240 alignment and 64 bit architectures made this impossible.
4242 Because for the time being no real solution for C++ parser
4243 generation exists, kludges were implemented in the parser to
4244 maintain this use. In the future, when Bison has C++ parsers, this
4245 kludge will be disabled.
4247 This kludge also addresses some C++ problems when the stack was
4251 * Noteworthy changes in release 1.34 (2002-03-12)
4253 ** File name clashes are detected
4254 $ bison foo.y -d -o foo.x
4255 fatal error: header and parser would both be named "foo.x"
4257 ** A missing ";" at the end of a rule triggers a warning
4258 In accordance with POSIX, and in agreement with other
4259 Yacc implementations, Bison will mandate this semicolon in the near
4260 future. This eases the implementation of a Bison parser of Bison
4261 grammars by making this grammar LALR(1) instead of LR(2). To
4262 facilitate the transition, this release introduces a warning.
4264 ** Revert the C++ namespace changes introduced in 1.31, as they caused too
4265 many portability hassles.
4267 ** DJGPP support added.
4269 ** Fix test suite portability problems.
4272 * Noteworthy changes in release 1.33 (2002-02-07)
4275 Groff could not be compiled for the definition of size_t was lacking
4276 under some conditions.
4282 * Noteworthy changes in release 1.32 (2002-01-23)
4284 ** Fix Yacc output file names
4286 ** Portability fixes
4288 ** Italian, Dutch translations
4291 * Noteworthy changes in release 1.31 (2002-01-14)
4295 ** GNU Gettext and %expect
4296 GNU Gettext asserts 10 s/r conflicts, but there are 7. Now that
4297 Bison dies on incorrect %expectations, we fear there will be
4298 too many bug reports for Gettext, so _for the time being_, %expect
4299 does not trigger an error when the input file is named "plural.y".
4301 ** Use of alloca in parsers
4302 If YYSTACK_USE_ALLOCA is defined to 0, then the parsers will use
4303 malloc exclusively. Since 1.29, but was not NEWS'ed.
4305 alloca is used only when compiled with GCC, to avoid portability
4308 ** yyparse now returns 2 if memory is exhausted; formerly it dumped core.
4310 ** When the generated parser lacks debugging code, YYDEBUG is now 0
4311 (as POSIX requires) instead of being undefined.
4314 Bison has always permitted actions such as { $$ = $1 }: it adds the
4315 ending semicolon. Now if in Yacc compatibility mode, the semicolon
4316 is no longer output: one has to write { $$ = $1; }.
4318 ** Better C++ compliance
4319 The output parsers try to respect C++ namespaces.
4320 [This turned out to be a failed experiment, and it was reverted later.]
4323 Fixed bugs when reporting useless nonterminals.
4326 The parsers work properly on 64 bit hosts.
4329 Some calls to strerror resulted in scrambled or missing error messages.
4332 When the number of shift/reduce conflicts is correct, don't issue
4335 ** The verbose report includes the rule line numbers.
4337 ** Rule line numbers are fixed in traces.
4339 ** Swedish translation
4342 Verbose parse error messages from the parsers are better looking.
4343 Before: parse error: unexpected `'/'', expecting `"number"' or `'-'' or `'(''
4344 Now: parse error: unexpected '/', expecting "number" or '-' or '('
4346 ** Fixed parser memory leaks.
4347 When the generated parser was using malloc to extend its stacks, the
4348 previous allocations were not freed.
4350 ** Fixed verbose output file.
4351 Some newlines were missing.
4352 Some conflicts in state descriptions were missing.
4354 ** Fixed conflict report.
4355 Option -v was needed to get the result.
4359 Mismatches are errors, not warnings.
4361 ** Fixed incorrect processing of some invalid input.
4363 ** Fixed CPP guards: 9foo.h uses BISON_9FOO_H instead of 9FOO_H.
4365 ** Fixed some typos in the documentation.
4367 ** %token MY_EOF 0 is supported.
4368 Before, MY_EOF was silently renumbered as 257.
4370 ** doc/refcard.tex is updated.
4372 ** %output, %file-prefix, %name-prefix.
4376 New, aliasing "--output-file".
4379 * Noteworthy changes in release 1.30 (2001-10-26)
4381 ** "--defines" and "--graph" have now an optional argument which is the
4382 output file name. "-d" and "-g" do not change; they do not take any
4385 ** "%source_extension" and "%header_extension" are removed, failed
4388 ** Portability fixes.
4391 * Noteworthy changes in release 1.29 (2001-09-07)
4393 ** The output file does not define const, as this caused problems when used
4394 with common autoconfiguration schemes. If you still use ancient compilers
4395 that lack const, compile with the equivalent of the C compiler option
4396 "-Dconst=". Autoconf's AC_C_CONST macro provides one way to do this.
4398 ** Added "-g" and "--graph".
4400 ** The Bison manual is now distributed under the terms of the GNU FDL.
4402 ** The input and the output files has automatically a similar extension.
4404 ** Russian translation added.
4406 ** NLS support updated; should hopefully be less troublesome.
4408 ** Added the old Bison reference card.
4410 ** Added "--locations" and "%locations".
4412 ** Added "-S" and "--skeleton".
4414 ** "%raw", "-r", "--raw" is disabled.
4416 ** Special characters are escaped when output. This solves the problems
4417 of the #line lines with path names including backslashes.
4420 "%yacc", "%fixed_output_files", "%defines", "%no_parser", "%verbose",
4421 "%debug", "%source_extension" and "%header_extension".
4424 Automatic location tracking.
4427 * Noteworthy changes in release 1.28 (1999-07-06)
4429 ** Should compile better now with K&R compilers.
4433 ** Fixed a problem with escaping the double quote character.
4435 ** There is now a FAQ.
4438 * Noteworthy changes in release 1.27
4440 ** The make rule which prevented bison.simple from being created on
4441 some systems has been fixed.
4444 * Noteworthy changes in release 1.26
4446 ** Bison now uses Automake.
4448 ** New mailing lists: <bug-bison@gnu.org> and <help-bison@gnu.org>.
4450 ** Token numbers now start at 257 as previously documented, not 258.
4452 ** Bison honors the TMPDIR environment variable.
4454 ** A couple of buffer overruns have been fixed.
4456 ** Problems when closing files should now be reported.
4458 ** Generated parsers should now work even on operating systems which do
4459 not provide alloca().
4462 * Noteworthy changes in release 1.25 (1995-10-16)
4464 ** Errors in the input grammar are not fatal; Bison keeps reading
4465 the grammar file, and reports all the errors found in it.
4467 ** Tokens can now be specified as multiple-character strings: for
4468 example, you could use "<=" for a token which looks like <=, instead
4469 of choosing a name like LESSEQ.
4471 ** The %token_table declaration says to write a table of tokens (names
4472 and numbers) into the parser file. The yylex function can use this
4473 table to recognize multiple-character string tokens, or for other
4476 ** The %no_lines declaration says not to generate any #line preprocessor
4477 directives in the parser file.
4479 ** The %raw declaration says to use internal Bison token numbers, not
4480 Yacc-compatible token numbers, when token names are defined as macros.
4482 ** The --no-parser option produces the parser tables without including
4483 the parser engine; a project can now use its own parser engine.
4484 The actions go into a separate file called NAME.act, in the form of
4485 a switch statement body.
4488 * Noteworthy changes in release 1.23
4490 The user can define YYPARSE_PARAM as the name of an argument to be
4491 passed into yyparse. The argument should have type void *. It should
4492 actually point to an object. Grammar actions can access the variable
4493 by casting it to the proper pointer type.
4495 Line numbers in output file corrected.
4498 * Noteworthy changes in release 1.22
4500 --help option added.
4503 * Noteworthy changes in release 1.20
4505 Output file does not redefine const for C++.
4509 LocalWords: yacc YYBACKUP glr GCC lalr ArrayIndexOutOfBoundsException nullptr
4510 LocalWords: cplusplus liby rpl fprintf mfcalc Wyacc stmt cond expr mk sym lr
4511 LocalWords: IELR ielr Lookahead YYERROR nonassoc LALR's api lookaheads yychar
4512 LocalWords: destructor lookahead YYRHSLOC YYLLOC Rhs ifndef YYFAIL cpp sr rr
4513 LocalWords: preprocessor initializer Wno Wnone Werror FreeBSD prec livelocks
4514 LocalWords: Solaris AIX UX RHEL Tru LHS gcc's Wundef YYENABLE NLS YYLTYPE VCG
4515 LocalWords: yyerror cpp's Wunused yylval yylloc prepend yyparse yylex yypush
4516 LocalWords: Graphviz xml nonterminals midrule destructor's YYSTYPE typedef ly
4517 LocalWords: CHR chr printf stdout namespace preprocessing enum pre include's
4518 LocalWords: YYRECOVERING nonfree destructors YYABORT YYACCEPT params enums de
4519 LocalWords: struct yystype DJGPP lex param Haible NUM alloca YYSTACK NUL goto
4520 LocalWords: YYMAXDEPTH Unescaped UCNs YYLTYPE's yyltype typedefs inline Yaccs
4521 LocalWords: Heriyanto Reenable dprec Hilfinger Eggert MYEOF Folle Menezes EOF
4522 LocalWords: Lackovic define's itemset Groff Gettext malloc NEWS'ed YYDEBUG YY
4523 LocalWords: namespaces strerror const autoconfiguration Dconst Autoconf's FDL
4524 LocalWords: Automake TMPDIR LESSEQ ylwrap endif yydebug YYTOKEN YYLSP ival hh
4525 LocalWords: extern YYTOKENTYPE TOKENTYPE yytokentype tokentype STYPE lval pdf
4526 LocalWords: lang yyoutput dvi html ps POSIX lvalp llocp Wother nterm arg init
4527 LocalWords: TOK calc yyo fval Wconflicts parsers yystackp yyval yynerrs
4528 LocalWords: Théophile Ranquet Santet fno fnone stype associativity Tolmer
4529 LocalWords: Wprecedence Rassoul Wempty Paolo Bonzini parser's Michiel loc
4530 LocalWords: redeclaration sval fcaret reentrant XSLT xsl Wmaybe yyvsp Tedi
4531 LocalWords: pragmas noreturn untyped Rozenman unexpanded Wojciech Polak
4532 LocalWords: Alexandre MERCHANTABILITY yytype emplace ptr automove lvalues
4533 LocalWords: nonterminal yy args Pragma dereference yyformat rhs docdir bw
4534 LocalWords: Redeclarations rpcalc Autoconf YFLAGS Makefiles PROG DECL num
4535 LocalWords: Heimbigner AST src ast Makefile srcdir MinGW xxlex XXSTYPE
4536 LocalWords: XXLTYPE strictfp IDEs ffixit fdiagnostics parseable fixits
4537 LocalWords: Wdeprecated yytext Variadic variadic yyrhs yyphrs RCS README
4538 LocalWords: noexcept constexpr ispell american deprecations backend Teoh
4539 LocalWords: YYPRINT Mangold Bonzini's Wdangling exVal baz checkable gcc
4540 LocalWords: fsanitize Vogelsgesang lis redeclared stdint automata yytname
4541 LocalWords: yysymbol yytnamerr yyreport ctx ARGMAX yysyntax stderr LPAREN
4542 LocalWords: symrec yypcontext TOKENMAX yyexpected YYEMPTY yypstate YYEOF
4543 LocalWords: autocompletion bistromathic submessages Cayuela lexcalc hoc
4544 LocalWords: yytoken YYUNDEF YYerror basename Automake's UTF ifdef ffile
4545 LocalWords: gotos readline Imbimbo Wcounterexamples Wcex Nonunifying rcex
4548 ispell-dictionary: "american"
4553 Copyright (C) 1995-2015, 2018-2020 Free Software Foundation, Inc.
4555 This file is part of Bison, the GNU Parser Generator.
4557 Permission is granted to copy, distribute and/or modify this document
4558 under the terms of the GNU Free Documentation License, Version 1.3 or
4559 any later version published by the Free Software Foundation; with no
4560 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
4561 Texts. A copy of the license is included in the "GNU Free
4562 Documentation License" file as part of this distribution.