]> git.saurik.com Git - bison.git/blob - NEWS
style: comment changes in Java skeleton
[bison.git] / NEWS
1 GNU Bison NEWS
2
3 * Noteworthy changes in release ?.? (????-??-??) [?]
4
5
6 * Noteworthy changes in release 2.7.90 (2013-05-30) [beta]
7
8 ** WARNING: Future backward-incompatibilities!
9
10 Like other GNU packages, Bison will start using some of the C99 features
11 for its own code, especially the definition of variables after statements.
12 The generated C parsers still aim at C90.
13
14 ** Backward incompatible changes
15
16 *** Obsolete features
17
18 Support for YYFAIL is removed (deprecated in Bison 2.4.2): use YYERROR.
19
20 Support for yystype and yyltype is removed (deprecated in Bison 1.875):
21 use YYSTYPE and YYLTYPE.
22
23 Support for YYLEX_PARAM and YYPARSE_PARAM is removed (deprecated in Bison
24 1.875): use %lex-param, %parse-param, or %param.
25
26 Missing semicolons at the end of actions are no longer added (as announced
27 in the release 2.5).
28
29 *** Use of YACC='bison -y'
30
31 TL;DR: With Autoconf <= 2.69, pass -Wno-yacc to (AM_)YFLAGS if you use
32 Bison extensions.
33
34 Traditional Yacc generates 'y.tab.c' whatever the name of the input file.
35 Therefore Makefiles written for Yacc expect 'y.tab.c' (and possibly
36 'y.tab.h' and 'y.outout') to be generated from 'foo.y'.
37
38 To this end, for ages, AC_PROG_YACC, Autoconf's macro to look for an
39 implementation of Yacc, was using Bison as 'bison -y'. While it does
40 ensure compatible output file names, it also enables warnings for
41 incompatibilities with POSIX Yacc. In other words, 'bison -y' triggers
42 warnings for Bison extensions.
43
44 Autoconf 2.70+ fixes this incompatibility by using YACC='bison -o y.tab.c'
45 (which also generates 'y.tab.h' and 'y.output' when needed).
46 Alternatively, disable Yacc warnings by passing '-Wno-yacc' to your Yacc
47 flags (YFLAGS, or AM_YFLAGS with Automake).
48
49 ** Bug fixes
50
51 *** The epilogue is no longer affected by internal #defines (glr.c)
52
53 The glr.c skeleton uses defines such as #define yylval (yystackp->yyval) in
54 generated code. These weren't properly undefined before the inclusion of
55 the user epilogue, so functions such as the following were butchered by the
56 preprocessor expansion:
57
58 int yylex (YYSTYPE *yylval);
59
60 This is fixed: yylval, yynerrs, yychar, and yylloc are now valid
61 identifiers for user-provided variables.
62
63 *** stdio.h is no longer needed when locations are enabled (yacc.c)
64
65 Changes in Bison 2.7 introduced a dependency on FILE and fprintf when
66 locations are enabled. This is fixed.
67
68 *** Warnings about useless %pure-parser/%define api.pure are restored
69
70 ** Diagnostics reported by Bison
71
72 Most of these features were contributed by Théophile Ranquet and Victor
73 Santet.
74
75 *** Carets
76
77 Version 2.7 introduced caret errors, for a prettier output. These are now
78 activated by default. The old format can still be used by invoking Bison
79 with -fno-caret (or -fnone).
80
81 Some error messages that reproduced excerpts of the grammar are now using
82 the caret information only. For instance on:
83
84 %%
85 exp: 'a' | 'a';
86
87 Bison 2.7 reports:
88
89 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
90 in.y:2.12-14: warning: rule useless in parser due to conflicts: exp: 'a' [-Wother]
91
92 Now bison reports:
93
94 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
95 in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
96 exp: 'a' | 'a';
97 ^^^
98
99 and "bison -fno-caret" reports:
100
101 in.y: warning: 1 reduce/reduce conflict [-Wconflicts-rr]
102 in.y:2.12-14: warning: rule useless in parser due to conflicts [-Wother]
103
104 *** Enhancements of the -Werror option
105
106 The -Werror=CATEGORY option is now recognized, and will treat specified
107 warnings as errors. The warnings need not have been explicitly activated
108 using the -W option, this is similar to what GCC 4.7 does.
109
110 For example, given the following command line, Bison will treat both
111 warnings related to POSIX Yacc incompatibilities and S/R conflicts as
112 errors (and only those):
113
114 $ bison -Werror=yacc,error=conflicts-sr input.y
115
116 If no categories are specified, -Werror will make all active warnings into
117 errors. For example, the following line does the same the previous example:
118
119 $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y
120
121 (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)
122
123 Note that the categories in this -Werror option may not be prefixed with
124 "no-". However, -Wno-error[=CATEGORY] is valid.
125
126 Note that -y enables -Werror=yacc. Therefore it is now possible to require
127 Yacc-like behavior (e.g., always generate y.tab.c), but to report
128 incompatibilities as warnings: "-y -Wno-error=yacc".
129
130 *** The display of warnings is now richer
131
132 The option that controls a given warning is now displayed:
133
134 foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
135
136 In the case of warnings treated as errors, the prefix is changed from
137 "warning: " to "error: ", and the suffix is displayed, in a manner similar
138 to GCC, as [-Werror=CATEGORY].
139
140 For instance, where the previous version of Bison would report (and exit
141 with failure):
142
143 bison: warnings being treated as errors
144 input.y:1.1: warning: stray ',' treated as white space
145
146 it now reports:
147
148 input.y:1.1: error: stray ',' treated as white space [-Werror=other]
149
150 *** Deprecated constructs
151
152 The new 'deprecated' warning category flags obsolete constructs whose
153 support will be discontinued. It is enabled by default. These warnings
154 used to be reported as 'other' warnings.
155
156 *** Useless semantic types
157
158 Bison now warns about useless (uninhabited) semantic types. Since
159 semantic types are not declared to Bison (they are defined in the opaque
160 %union structure), it is %printer/%destructor directives about useless
161 types that trigger the warning:
162
163 %token <type1> term
164 %type <type2> nterm
165 %printer {} <type1> <type3>
166 %destructor {} <type2> <type4>
167 %%
168 nterm: term { $$ = $1; };
169
170 3.28-34: warning: type <type3> is used, but is not associated to any symbol
171 4.28-34: warning: type <type4> is used, but is not associated to any symbol
172
173 *** Undefined but unused symbols
174
175 Bison used to raise an error for undefined symbols that are not used in
176 the grammar. This is now only a warning.
177
178 %printer {} symbol1
179 %destructor {} symbol2
180 %type <type> symbol3
181 %%
182 exp: "a";
183
184 *** Useless destructors or printers
185
186 Bison now warns about useless destructors or printers. In the following
187 example, the printer for <type1>, and the destructor for <type2> are
188 useless: all symbols of <type1> (token1) already have a printer, and all
189 symbols of type <type2> (token2) already have a destructor.
190
191 %token <type1> token1
192 <type2> token2
193 <type3> token3
194 <type4> token4
195 %printer {} token1 <type1> <type3>
196 %destructor {} token2 <type2> <type4>
197
198 *** Conflicts
199
200 The warnings and error messages about shift/reduce and reduce/reduce
201 conflicts have been normalized. For instance on the following foo.y file:
202
203 %glr-parser
204 %%
205 exp: exp '+' exp | '0' | '0';
206
207 compare the previous version of bison:
208
209 $ bison foo.y
210 foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
211 $ bison -Werror foo.y
212 bison: warnings being treated as errors
213 foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
214
215 with the new behavior:
216
217 $ bison foo.y
218 foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
219 foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
220 $ bison -Werror foo.y
221 foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
222 foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]
223
224 When %expect or %expect-rr is used, such as with bar.y:
225
226 %expect 0
227 %glr-parser
228 %%
229 exp: exp '+' exp | '0' | '0';
230
231 Former behavior:
232
233 $ bison bar.y
234 bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
235 bar.y: expected 0 shift/reduce conflicts
236 bar.y: expected 0 reduce/reduce conflicts
237
238 New one:
239
240 $ bison bar.y
241 bar.y: error: shift/reduce conflicts: 1 found, 0 expected
242 bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
243
244 ** Incompatibilities with POSIX Yacc
245
246 The 'yacc' category is no longer part of '-Wall', enable it explicitly
247 with '-Wyacc'.
248
249 ** Additional yylex/yyparse arguments
250
251 The new directive %param declares additional arguments to both yylex and
252 yyparse. The %lex-param, %parse-param, and %param directives support one
253 or more arguments. Instead of
254
255 %lex-param {arg1_type *arg1}
256 %lex-param {arg2_type *arg2}
257 %parse-param {arg1_type *arg1}
258 %parse-param {arg2_type *arg2}
259
260 one may now declare
261
262 %param {arg1_type *arg1} {arg2_type *arg2}
263
264 ** Types of values for %define variables
265
266 Bison used to make no difference between '%define foo bar' and '%define
267 foo "bar"'. The former is now called a 'keyword value', and the latter a
268 'string value'. A third kind was added: 'code values', such as '%define
269 foo {bar}'.
270
271 Keyword variables are used for fixed value sets, e.g.,
272
273 %define lr.type lalr
274
275 Code variables are used for value in the target language, e.g.,
276
277 %define api.value.type {struct semantic_type}
278
279 String variables are used remaining cases, e.g. file names.
280
281 ** Variable api.token.prefix
282
283 The variable api.token.prefix changes the way tokens are identified in
284 the generated files. This is especially useful to avoid collisions
285 with identifiers in the target language. For instance
286
287 %token FILE for ERROR
288 %define api.token.prefix {TOK_}
289 %%
290 start: FILE for ERROR;
291
292 will generate the definition of the symbols TOK_FILE, TOK_for, and
293 TOK_ERROR in the generated sources. In particular, the scanner must
294 use these prefixed token names, although the grammar itself still
295 uses the short names (as in the sample rule given above).
296
297 ** Variable api.value.type
298
299 This new %define variable supersedes the #define macro YYSTYPE. The use
300 of YYSTYPE is discouraged. In particular, #defining YYSTYPE *and* either
301 using %union or %defining api.value.type results in undefined behavior.
302
303 Either define api.value.type, or use "%union":
304
305 %union
306 {
307 int ival;
308 char *sval;
309 }
310 %token <ival> INT "integer"
311 %token <sval> STRING "string"
312 %printer { fprintf (yyo, "%d", $$); } <ival>
313 %destructor { free ($$); } <sval>
314
315 /* In yylex(). */
316 yylval.ival = 42; return INT;
317 yylval.sval = "42"; return STRING;
318
319 The %define variable api.value.type supports both keyword and code values.
320
321 The keyword value 'union' means that the user provides genuine types, not
322 union member names such as "ival" and "sval" above (WARNING: will fail if
323 -y/--yacc/%yacc is enabled).
324
325 %define api.value.type union
326 %token <int> INT "integer"
327 %token <char *> STRING "string"
328 %printer { fprintf (yyo, "%d", $$); } <int>
329 %destructor { free ($$); } <char *>
330
331 /* In yylex(). */
332 yylval.INT = 42; return INT;
333 yylval.STRING = "42"; return STRING;
334
335 The keyword value variant is somewhat equivalent, but for C++ special
336 provision is made to allow classes to be used (more about this below).
337
338 %define api.value.type variant
339 %token <int> INT "integer"
340 %token <std::string> STRING "string"
341
342 Code values (in braces) denote user defined types. This is where YYSTYPE
343 used to be used.
344
345 %code requires
346 {
347 struct my_value
348 {
349 enum
350 {
351 is_int, is_string
352 } kind;
353 union
354 {
355 int ival;
356 char *sval;
357 } u;
358 };
359 }
360 %define api.value.type {struct my_value}
361 %token <u.ival> INT "integer"
362 %token <u.sval> STRING "string"
363 %printer { fprintf (yyo, "%d", $$); } <u.ival>
364 %destructor { free ($$); } <u.sval>
365
366 /* In yylex(). */
367 yylval.u.ival = 42; return INT;
368 yylval.u.sval = "42"; return STRING;
369
370 ** Variable parse.error
371
372 This variable controls the verbosity of error messages. The use of the
373 %error-verbose directive is deprecated in favor of "%define parse.error
374 verbose".
375
376 ** Renamed %define variables
377
378 The following variables have been renamed for consistency. Backward
379 compatibility is ensured, but upgrading is recommended.
380
381 lr.default-reductions -> lr.default-reduction
382 lr.keep-unreachable-states -> lr.keep-unreachable-state
383 namespace -> api.namespace
384 stype -> api.value.type
385
386 ** Semantic predicates
387
388 Contributed by Paul Hilfinger.
389
390 The new, experimental, semantic-predicate feature allows actions of the
391 form "%?{ BOOLEAN-EXPRESSION }", which cause syntax errors (as for
392 YYERROR) if the expression evaluates to 0, and are evaluated immediately
393 in GLR parsers, rather than being deferred. The result is that they allow
394 the programmer to prune possible parses based on the values of run-time
395 expressions.
396
397 ** The directive %expect-rr is now an error in non GLR mode
398
399 It used to be an error only if used in non GLR mode, _and_ if there are
400 reduce/reduce conflicts.
401
402 ** Tokens are numbered in their order of appearance
403
404 Contributed by Valentin Tolmer.
405
406 With '%token A B', A had a number less than the one of B. However,
407 precedence declarations used to generate a reversed order. This is now
408 fixed, and introducing tokens with any of %token, %left, %right,
409 %precedence, or %nonassoc yields the same result.
410
411 When mixing declarations of tokens with a litteral character (e.g., 'a')
412 or with an identifier (e.g., B) in a precedence declaration, Bison
413 numbered the litteral characters first. For example
414
415 %right A B 'c' 'd'
416
417 would lead to the tokens declared in this order: 'c' 'd' A B. Again, the
418 input order is now preserved.
419
420 These changes were made so that one can remove useless precedence and
421 associativity declarations (i.e., map %nonassoc, %left or %right to
422 %precedence, or to %token) and get exactly the same output.
423
424 ** Useless precedence and associativity
425
426 Contributed by Valentin Tolmer.
427
428 When developing and maintaining a grammar, useless associativity and
429 precedence directives are common. They can be a nuisance: new ambiguities
430 arising are sometimes masked because their conflicts are resolved due to
431 the extra precedence or associativity information. Furthermore, it can
432 hinder the comprehension of a new grammar: one will wonder about the role
433 of a precedence, where in fact it is useless. The following changes aim
434 at detecting and reporting these extra directives.
435
436 *** Precedence warning category
437
438 A new category of warning, -Wprecedence, was introduced. It flags the
439 useless precedence and associativity directives.
440
441 *** Useless associativity
442
443 Bison now warns about symbols with a declared associativity that is never
444 used to resolve conflicts. In that case, using %precedence is sufficient;
445 the parsing tables will remain unchanged. Solving these warnings may raise
446 useless precedence warnings, as the symbols no longer have associativity.
447 For example:
448
449 %left '+'
450 %left '*'
451 %%
452 exp:
453 "number"
454 | exp '+' "number"
455 | exp '*' exp
456 ;
457
458 will produce a
459
460 warning: useless associativity for '+', use %precedence [-Wprecedence]
461 %left '+'
462 ^^^
463
464 *** Useless precedence
465
466 Bison now warns about symbols with a declared precedence and no declared
467 associativity (i.e., declared with %precedence), and whose precedence is
468 never used. In that case, the symbol can be safely declared with %token
469 instead, without modifying the parsing tables. For example:
470
471 %precedence '='
472 %%
473 exp: "var" '=' "number";
474
475 will produce a
476
477 warning: useless precedence for '=' [-Wprecedence]
478 %precedence '='
479 ^^^
480
481 *** Useless precedence and associativity
482
483 In case of both useless precedence and associativity, the issue is flagged
484 as follows:
485
486 %nonassoc '='
487 %%
488 exp: "var" '=' "number";
489
490 The warning is:
491
492 warning: useless precedence and associativity for '=' [-Wprecedence]
493 %nonassoc '='
494 ^^^
495
496 ** Empty rules
497
498 With help from Joel E. Denny and Gabriel Rassoul.
499
500 Empty rules (i.e., with an empty right-hand side) can now be explicitly
501 marked by the new %empty directive. Using %empty on a non-empty rule is
502 an error. The new -Wempty-rule warning reports empty rules without
503 %empty. On the following grammar:
504
505 %%
506 s: a b c;
507 a: ;
508 b: %empty;
509 c: 'a' %empty;
510
511 bison reports:
512
513 3.4-5: warning: empty rule without %empty [-Wempty-rule]
514 a: {}
515 ^^
516 5.8-13: error: %empty on non-empty rule
517 c: 'a' %empty {};
518 ^^^^^^
519
520 ** Java skeleton improvements
521
522 Contributed by Paolo Bonzini.
523
524 The constants for token names were moved to the Lexer interface. Also, it
525 is possible to add code to the parser's constructors using "%code init"
526 and "%define init_throws".
527
528 ** C++ skeletons improvements
529
530 *** The parser header is no longer mandatory (lalr1.cc, glr.cc)
531
532 Using %defines is now optional. Without it, the needed support classes
533 are defined in the generated parser, instead of additional files (such as
534 location.hh, position.hh and stack.hh).
535
536 *** Locations are no longer mandatory (lalr1.cc, glr.cc)
537
538 Both lalr1.cc and glr.cc no longer require %location.
539
540 *** syntax_error exception (lalr1.cc)
541
542 The C++ parser features a syntax_error exception, which can be
543 thrown from the scanner or from user rules to raise syntax errors.
544 This facilitates reporting errors caught in sub-functions (e.g.,
545 rejecting too large integral literals from a conversion function
546 used by the scanner, or rejecting invalid combinations from a
547 factory invoked by the user actions).
548
549 *** %define api.value.type variant
550
551 This is based on a submission from Michiel De Wilde. With help
552 from Théophile Ranquet.
553
554 In this mode, complex C++ objects can be used as semantic values. For
555 instance:
556
557 %token <::std::string> TEXT;
558 %token <int> NUMBER;
559 %token SEMICOLON ";"
560 %type <::std::string> item;
561 %type <::std::list<std::string>> list;
562 %%
563 result:
564 list { std::cout << $1 << std::endl; }
565 ;
566
567 list:
568 %empty { /* Generates an empty string list. */ }
569 | list item ";" { std::swap ($$, $1); $$.push_back ($2); }
570 ;
571
572 item:
573 TEXT { std::swap ($$, $1); }
574 | NUMBER { $$ = string_cast ($1); }
575 ;
576
577 *** %define api.token.constructor
578
579 When variants are enabled, Bison can generate functions to build the
580 tokens. This guarantees that the token type (e.g., NUMBER) is consistent
581 with the semantic value (e.g., int):
582
583 parser::symbol_type yylex ()
584 {
585 parser::location_type loc = ...;
586 ...
587 return parser::make_TEXT ("Hello, world!", loc);
588 ...
589 return parser::make_NUMBER (42, loc);
590 ...
591 return parser::make_SEMICOLON (loc);
592 ...
593 }
594
595 *** C++ locations
596
597 There are operator- and operator-= for 'location'. Negative line/column
598 increments can no longer underflow the resulting value.
599
600 * Noteworthy changes in release 2.7.1 (2013-04-15) [stable]
601
602 ** Bug fixes
603
604 *** Fix compiler attribute portability (yacc.c)
605
606 With locations enabled, __attribute__ was used unprotected.
607
608 *** Fix some compiler warnings (lalr1.cc)
609
610 * Noteworthy changes in release 2.7 (2012-12-12) [stable]
611
612 ** Bug fixes
613
614 Warnings about uninitialized yylloc in yyparse have been fixed.
615
616 Restored C90 compliance (yet no report was ever made).
617
618 ** Diagnostics are improved
619
620 Contributed by Théophile Ranquet.
621
622 *** Changes in the format of error messages
623
624 This used to be the format of many error reports:
625
626 input.y:2.7-12: %type redeclaration for exp
627 input.y:1.7-12: previous declaration
628
629 It is now:
630
631 input.y:2.7-12: error: %type redeclaration for exp
632 input.y:1.7-12: previous declaration
633
634 *** New format for error reports: carets
635
636 Caret errors have been added to Bison:
637
638 input.y:2.7-12: error: %type redeclaration for exp
639 %type <sval> exp
640 ^^^^^^
641 input.y:1.7-12: previous declaration
642 %type <ival> exp
643 ^^^^^^
644
645 or
646
647 input.y:3.20-23: error: ambiguous reference: '$exp'
648 exp: exp '+' exp { $exp = $1 + $3; };
649 ^^^^
650 input.y:3.1-3: refers to: $exp at $$
651 exp: exp '+' exp { $exp = $1 + $3; };
652 ^^^
653 input.y:3.6-8: refers to: $exp at $1
654 exp: exp '+' exp { $exp = $1 + $3; };
655 ^^^
656 input.y:3.14-16: refers to: $exp at $3
657 exp: exp '+' exp { $exp = $1 + $3; };
658 ^^^
659
660 The default behavior for now is still not to display these unless
661 explicitly asked with -fcaret (or -fall). However, in a later release, it
662 will be made the default behavior (but may still be deactivated with
663 -fno-caret).
664
665 ** New value for %define variable: api.pure full
666
667 The %define variable api.pure requests a pure (reentrant) parser. However,
668 for historical reasons, using it in a location-tracking Yacc parser
669 resulted in a yyerror function that did not take a location as a
670 parameter. With this new value, the user may request a better pure parser,
671 where yyerror does take a location as a parameter (in location-tracking
672 parsers).
673
674 The use of "%define api.pure true" is deprecated in favor of this new
675 "%define api.pure full".
676
677 ** New %define variable: api.location.type (glr.cc, lalr1.cc, lalr1.java)
678
679 The %define variable api.location.type defines the name of the type to use
680 for locations. When defined, Bison no longer generates the position.hh
681 and location.hh files, nor does the parser will include them: the user is
682 then responsible to define her type.
683
684 This can be used in programs with several parsers to factor their location
685 and position files: let one of them generate them, and the others just use
686 them.
687
688 This feature was actually introduced, but not documented, in Bison 2.5,
689 under the name "location_type" (which is maintained for backward
690 compatibility).
691
692 For consistency, lalr1.java's %define variables location_type and
693 position_type are deprecated in favor of api.location.type and
694 api.position.type.
695
696 ** Exception safety (lalr1.cc)
697
698 The parse function now catches exceptions, uses the %destructors to
699 release memory (the lookahead symbol and the symbols pushed on the stack)
700 before re-throwing the exception.
701
702 This feature is somewhat experimental. User feedback would be
703 appreciated.
704
705 ** Graph improvements in DOT and XSLT
706
707 Contributed by Théophile Ranquet.
708
709 The graphical presentation of the states is more readable: their shape is
710 now rectangular, the state number is clearly displayed, and the items are
711 numbered and left-justified.
712
713 The reductions are now explicitly represented as transitions to other
714 diamond shaped nodes.
715
716 These changes are present in both --graph output and xml2dot.xsl XSLT
717 processing, with minor (documented) differences.
718
719 ** %language is no longer an experimental feature.
720
721 The introduction of this feature, in 2.4, was four years ago. The
722 --language option and the %language directive are no longer experimental.
723
724 ** Documentation
725
726 The sections about shift/reduce and reduce/reduce conflicts resolution
727 have been fixed and extended.
728
729 Although introduced more than four years ago, XML and Graphviz reports
730 were not properly documented.
731
732 The translation of mid-rule actions is now described.
733
734 * Noteworthy changes in release 2.6.5 (2012-11-07) [stable]
735
736 We consider compiler warnings about Bison generated parsers to be bugs.
737 Rather than working around them in your own project, please consider
738 reporting them to us.
739
740 ** Bug fixes
741
742 Warnings about uninitialized yylval and/or yylloc for push parsers with a
743 pure interface have been fixed for GCC 4.0 up to 4.8, and Clang 2.9 to
744 3.2.
745
746 Other issues in the test suite have been addressed.
747
748 Null characters are correctly displayed in error messages.
749
750 When possible, yylloc is correctly initialized before calling yylex. It
751 is no longer necessary to initialize it in the %initial-action.
752
753 * Noteworthy changes in release 2.6.4 (2012-10-23) [stable]
754
755 Bison 2.6.3's --version was incorrect. This release fixes this issue.
756
757 * Noteworthy changes in release 2.6.3 (2012-10-22) [stable]
758
759 ** Bug fixes
760
761 Bugs and portability issues in the test suite have been fixed.
762
763 Some errors in translations have been addressed, and --help now directs
764 users to the appropriate place to report them.
765
766 Stray Info files shipped by accident are removed.
767
768 Incorrect definitions of YY_, issued by yacc.c when no parser header is
769 generated, are removed.
770
771 All the generated headers are self-contained.
772
773 ** Header guards (yacc.c, glr.c, glr.cc)
774
775 In order to avoid collisions, the header guards are now
776 YY_<PREFIX>_<FILE>_INCLUDED, instead of merely <PREFIX>_<FILE>.
777 For instance the header generated from
778
779 %define api.prefix "calc"
780 %defines "lib/parse.h"
781
782 will use YY_CALC_LIB_PARSE_H_INCLUDED as guard.
783
784 ** Fix compiler warnings in the generated parser (yacc.c, glr.c)
785
786 The compilation of pure parsers (%define api.pure) can trigger GCC
787 warnings such as:
788
789 input.c: In function 'yyparse':
790 input.c:1503:12: warning: 'yylval' may be used uninitialized in this
791 function [-Wmaybe-uninitialized]
792 *++yyvsp = yylval;
793 ^
794
795 This is now fixed; pragmas to avoid these warnings are no longer needed.
796
797 Warnings from clang ("equality comparison with extraneous parentheses" and
798 "function declared 'noreturn' should not return") have also been
799 addressed.
800
801 * Noteworthy changes in release 2.6.2 (2012-08-03) [stable]
802
803 ** Bug fixes
804
805 Buffer overruns, complaints from Flex, and portability issues in the test
806 suite have been fixed.
807
808 ** Spaces in %lex- and %parse-param (lalr1.cc, glr.cc)
809
810 Trailing end-of-lines in %parse-param or %lex-param would result in
811 invalid C++. This is fixed.
812
813 ** Spurious spaces and end-of-lines
814
815 The generated files no longer end (nor start) with empty lines.
816
817 * Noteworthy changes in release 2.6.1 (2012-07-30) [stable]
818
819 Bison no longer executes user-specified M4 code when processing a grammar.
820
821 ** Future Changes
822
823 In addition to the removal of the features announced in Bison 2.6, the
824 next major release will remove the "Temporary hack for adding a semicolon
825 to the user action", as announced in the release 2.5. Instead of:
826
827 exp: exp "+" exp { $$ = $1 + $3 };
828
829 write:
830
831 exp: exp "+" exp { $$ = $1 + $3; };
832
833 ** Bug fixes
834
835 *** Type names are now properly escaped.
836
837 *** glr.cc: set_debug_level and debug_level work as expected.
838
839 *** Stray @ or $ in actions
840
841 While Bison used to warn about stray $ or @ in action rules, it did not
842 for other actions such as printers, destructors, or initial actions. It
843 now does.
844
845 ** Type names in actions
846
847 For consistency with rule actions, it is now possible to qualify $$ by a
848 type-name in destructors, printers, and initial actions. For instance:
849
850 %printer { fprintf (yyo, "(%d, %f)", $<ival>$, $<fval>$); } <*> <>;
851
852 will display two values for each typed and untyped symbol (provided
853 that YYSTYPE has both "ival" and "fval" fields).
854
855 * Noteworthy changes in release 2.6 (2012-07-19) [stable]
856
857 ** Future changes
858
859 The next major release of Bison will drop support for the following
860 deprecated features. Please report disagreements to bug-bison@gnu.org.
861
862 *** K&R C parsers
863
864 Support for generating parsers in K&R C will be removed. Parsers
865 generated for C support ISO C90, and are tested with ISO C99 and ISO C11
866 compilers.
867
868 *** Features deprecated since Bison 1.875
869
870 The definitions of yystype and yyltype will be removed; use YYSTYPE and
871 YYLTYPE.
872
873 YYPARSE_PARAM and YYLEX_PARAM, deprecated in favor of %parse-param and
874 %lex-param, will no longer be supported.
875
876 Support for the preprocessor symbol YYERROR_VERBOSE will be removed, use
877 %error-verbose.
878
879 *** The generated header will be included (yacc.c)
880
881 Instead of duplicating the content of the generated header (definition of
882 YYSTYPE, yyparse declaration etc.), the generated parser will include it,
883 as is already the case for GLR or C++ parsers. This change is deferred
884 because existing versions of ylwrap (e.g., Automake 1.12.1) do not support
885 it.
886
887 ** Generated Parser Headers
888
889 *** Guards (yacc.c, glr.c, glr.cc)
890
891 The generated headers are now guarded, as is already the case for C++
892 parsers (lalr1.cc). For instance, with --defines=foo.h:
893
894 #ifndef YY_FOO_H
895 # define YY_FOO_H
896 ...
897 #endif /* !YY_FOO_H */
898
899 *** New declarations (yacc.c, glr.c)
900
901 The generated header now declares yydebug and yyparse. Both honor
902 --name-prefix=bar_, and yield
903
904 int bar_parse (void);
905
906 rather than
907
908 #define yyparse bar_parse
909 int yyparse (void);
910
911 in order to facilitate the inclusion of several parser headers inside a
912 single compilation unit.
913
914 *** Exported symbols in C++
915
916 The symbols YYTOKEN_TABLE and YYERROR_VERBOSE, which were defined in the
917 header, are removed, as they prevent the possibility of including several
918 generated headers from a single compilation unit.
919
920 *** YYLSP_NEEDED
921
922 For the same reasons, the undocumented and unused macro YYLSP_NEEDED is no
923 longer defined.
924
925 ** New %define variable: api.prefix
926
927 Now that the generated headers are more complete and properly protected
928 against multiple inclusions, constant names, such as YYSTYPE are a
929 problem. While yyparse and others are properly renamed by %name-prefix,
930 YYSTYPE, YYDEBUG and others have never been affected by it. Because it
931 would introduce backward compatibility issues in projects not expecting
932 YYSTYPE to be renamed, instead of changing the behavior of %name-prefix,
933 it is deprecated in favor of a new %define variable: api.prefix.
934
935 The following examples compares both:
936
937 %name-prefix "bar_" | %define api.prefix "bar_"
938 %token <ival> FOO %token <ival> FOO
939 %union { int ival; } %union { int ival; }
940 %% %%
941 exp: 'a'; exp: 'a';
942
943 bison generates:
944
945 #ifndef BAR_FOO_H #ifndef BAR_FOO_H
946 # define BAR_FOO_H # define BAR_FOO_H
947
948 /* Enabling traces. */ /* Enabling traces. */
949 # ifndef YYDEBUG | # ifndef BAR_DEBUG
950 > # if defined YYDEBUG
951 > # if YYDEBUG
952 > # define BAR_DEBUG 1
953 > # else
954 > # define BAR_DEBUG 0
955 > # endif
956 > # else
957 # define YYDEBUG 0 | # define BAR_DEBUG 0
958 > # endif
959 # endif | # endif
960
961 # if YYDEBUG | # if BAR_DEBUG
962 extern int bar_debug; extern int bar_debug;
963 # endif # endif
964
965 /* Tokens. */ /* Tokens. */
966 # ifndef YYTOKENTYPE | # ifndef BAR_TOKENTYPE
967 # define YYTOKENTYPE | # define BAR_TOKENTYPE
968 enum yytokentype { | enum bar_tokentype {
969 FOO = 258 FOO = 258
970 }; };
971 # endif # endif
972
973 #if ! defined YYSTYPE \ | #if ! defined BAR_STYPE \
974 && ! defined YYSTYPE_IS_DECLARED | && ! defined BAR_STYPE_IS_DECLARED
975 typedef union YYSTYPE | typedef union BAR_STYPE
976 { {
977 int ival; int ival;
978 } YYSTYPE; | } BAR_STYPE;
979 # define YYSTYPE_IS_DECLARED 1 | # define BAR_STYPE_IS_DECLARED 1
980 #endif #endif
981
982 extern YYSTYPE bar_lval; | extern BAR_STYPE bar_lval;
983
984 int bar_parse (void); int bar_parse (void);
985
986 #endif /* !BAR_FOO_H */ #endif /* !BAR_FOO_H */
987
988 * Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
989
990 ** Future changes:
991
992 The next major release will drop support for generating parsers in K&R C.
993
994 ** yacc.c: YYBACKUP works as expected.
995
996 ** glr.c improvements:
997
998 *** Location support is eliminated when not requested:
999
1000 GLR parsers used to include location-related code even when locations were
1001 not requested, and therefore not even usable.
1002
1003 *** __attribute__ is preserved:
1004
1005 __attribute__ is no longer disabled when __STRICT_ANSI__ is defined (i.e.,
1006 when -std is passed to GCC).
1007
1008 ** lalr1.java: several fixes:
1009
1010 The Java parser no longer throws ArrayIndexOutOfBoundsException if the
1011 first token leads to a syntax error. Some minor clean ups.
1012
1013 ** Changes for C++:
1014
1015 *** C++11 compatibility:
1016
1017 C and C++ parsers use "nullptr" instead of "0" when __cplusplus is 201103L
1018 or higher.
1019
1020 *** Header guards
1021
1022 The header files such as "parser.hh", "location.hh", etc. used a constant
1023 name for preprocessor guards, for instance:
1024
1025 #ifndef BISON_LOCATION_HH
1026 # define BISON_LOCATION_HH
1027 ...
1028 #endif // !BISON_LOCATION_HH
1029
1030 The inclusion guard is now computed from "PREFIX/FILE-NAME", where lower
1031 case characters are converted to upper case, and series of
1032 non-alphanumerical characters are converted to an underscore.
1033
1034 With "bison -o lang++/parser.cc", "location.hh" would now include:
1035
1036 #ifndef YY_LANG_LOCATION_HH
1037 # define YY_LANG_LOCATION_HH
1038 ...
1039 #endif // !YY_LANG_LOCATION_HH
1040
1041 *** C++ locations:
1042
1043 The position and location constructors (and their initialize methods)
1044 accept new arguments for line and column. Several issues in the
1045 documentation were fixed.
1046
1047 ** liby is no longer asking for "rpl_fprintf" on some platforms.
1048
1049 ** Changes in the manual:
1050
1051 *** %printer is documented
1052
1053 The "%printer" directive, supported since at least Bison 1.50, is finally
1054 documented. The "mfcalc" example is extended to demonstrate it.
1055
1056 For consistency with the C skeletons, the C++ parsers now also support
1057 "yyoutput" (as an alias to "debug_stream ()").
1058
1059 *** Several improvements have been made:
1060
1061 The layout for grammar excerpts was changed to a more compact scheme.
1062 Named references are motivated. The description of the automaton
1063 description file (*.output) is updated to the current format. Incorrect
1064 index entries were fixed. Some other errors were fixed.
1065
1066 ** Building bison:
1067
1068 *** Conflicting prototypes with recent/modified Flex.
1069
1070 Fixed build problems with the current, unreleased, version of Flex, and
1071 some modified versions of 2.5.35, which have modified function prototypes.
1072
1073 *** Warnings during the build procedure have been eliminated.
1074
1075 *** Several portability problems in the test suite have been fixed:
1076
1077 This includes warnings with some compilers, unexpected behavior of tools
1078 such as diff, warning messages from the test suite itself, etc.
1079
1080 *** The install-pdf target works properly:
1081
1082 Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
1083 halts in the middle of its course.
1084
1085 * Changes in version 2.5 (2011-05-14):
1086
1087 ** Grammar symbol names can now contain non-initial dashes:
1088
1089 Consistently with directives (such as %error-verbose) and with
1090 %define variables (e.g. push-pull), grammar symbol names may contain
1091 dashes in any position except the beginning. This is a GNU
1092 extension over POSIX Yacc. Thus, use of this extension is reported
1093 by -Wyacc and rejected in Yacc mode (--yacc).
1094
1095 ** Named references:
1096
1097 Historically, Yacc and Bison have supported positional references
1098 ($n, $$) to allow access to symbol values from inside of semantic
1099 actions code.
1100
1101 Starting from this version, Bison can also accept named references.
1102 When no ambiguity is possible, original symbol names may be used
1103 as named references:
1104
1105 if_stmt : "if" cond_expr "then" then_stmt ';'
1106 { $if_stmt = mk_if_stmt($cond_expr, $then_stmt); }
1107
1108 In the more common case, explicit names may be declared:
1109
1110 stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
1111 { $res = mk_if_stmt($cond, $then, $else); }
1112
1113 Location information is also accessible using @name syntax. When
1114 accessing symbol names containing dots or dashes, explicit bracketing
1115 ($[sym.1]) must be used.
1116
1117 These features are experimental in this version. More user feedback
1118 will help to stabilize them.
1119 Contributed by Alex Rozenman.
1120
1121 ** IELR(1) and canonical LR(1):
1122
1123 IELR(1) is a minimal LR(1) parser table generation algorithm. That
1124 is, given any context-free grammar, IELR(1) generates parser tables
1125 with the full language-recognition power of canonical LR(1) but with
1126 nearly the same number of parser states as LALR(1). This reduction
1127 in parser states is often an order of magnitude. More importantly,
1128 because canonical LR(1)'s extra parser states may contain duplicate
1129 conflicts in the case of non-LR(1) grammars, the number of conflicts
1130 for IELR(1) is often an order of magnitude less as well. This can
1131 significantly reduce the complexity of developing of a grammar.
1132
1133 Bison can now generate IELR(1) and canonical LR(1) parser tables in
1134 place of its traditional LALR(1) parser tables, which remain the
1135 default. You can specify the type of parser tables in the grammar
1136 file with these directives:
1137
1138 %define lr.type lalr
1139 %define lr.type ielr
1140 %define lr.type canonical-lr
1141
1142 The default-reduction optimization in the parser tables can also be
1143 adjusted using "%define lr.default-reductions". For details on both
1144 of these features, see the new section "Tuning LR" in the Bison
1145 manual.
1146
1147 These features are experimental. More user feedback will help to
1148 stabilize them.
1149
1150 ** LAC (Lookahead Correction) for syntax error handling
1151
1152 Contributed by Joel E. Denny.
1153
1154 Canonical LR, IELR, and LALR can suffer from a couple of problems
1155 upon encountering a syntax error. First, the parser might perform
1156 additional parser stack reductions before discovering the syntax
1157 error. Such reductions can perform user semantic actions that are
1158 unexpected because they are based on an invalid token, and they
1159 cause error recovery to begin in a different syntactic context than
1160 the one in which the invalid token was encountered. Second, when
1161 verbose error messages are enabled (with %error-verbose or the
1162 obsolete "#define YYERROR_VERBOSE"), the expected token list in the
1163 syntax error message can both contain invalid tokens and omit valid
1164 tokens.
1165
1166 The culprits for the above problems are %nonassoc, default
1167 reductions in inconsistent states, and parser state merging. Thus,
1168 IELR and LALR suffer the most. Canonical LR can suffer only if
1169 %nonassoc is used or if default reductions are enabled for
1170 inconsistent states.
1171
1172 LAC is a new mechanism within the parsing algorithm that solves
1173 these problems for canonical LR, IELR, and LALR without sacrificing
1174 %nonassoc, default reductions, or state merging. When LAC is in
1175 use, canonical LR and IELR behave almost exactly the same for both
1176 syntactically acceptable and syntactically unacceptable input.
1177 While LALR still does not support the full language-recognition
1178 power of canonical LR and IELR, LAC at least enables LALR's syntax
1179 error handling to correctly reflect LALR's language-recognition
1180 power.
1181
1182 Currently, LAC is only supported for deterministic parsers in C.
1183 You can enable LAC with the following directive:
1184
1185 %define parse.lac full
1186
1187 See the new section "LAC" in the Bison manual for additional
1188 details including a few caveats.
1189
1190 LAC is an experimental feature. More user feedback will help to
1191 stabilize it.
1192
1193 ** %define improvements:
1194
1195 *** Can now be invoked via the command line:
1196
1197 Each of these command-line options
1198
1199 -D NAME[=VALUE]
1200 --define=NAME[=VALUE]
1201
1202 -F NAME[=VALUE]
1203 --force-define=NAME[=VALUE]
1204
1205 is equivalent to this grammar file declaration
1206
1207 %define NAME ["VALUE"]
1208
1209 except that the manner in which Bison processes multiple definitions
1210 for the same NAME differs. Most importantly, -F and --force-define
1211 quietly override %define, but -D and --define do not. For further
1212 details, see the section "Bison Options" in the Bison manual.
1213
1214 *** Variables renamed:
1215
1216 The following %define variables
1217
1218 api.push_pull
1219 lr.keep_unreachable_states
1220
1221 have been renamed to
1222
1223 api.push-pull
1224 lr.keep-unreachable-states
1225
1226 The old names are now deprecated but will be maintained indefinitely
1227 for backward compatibility.
1228
1229 *** Values no longer need to be quoted in the grammar file:
1230
1231 If a %define value is an identifier, it no longer needs to be placed
1232 within quotations marks. For example,
1233
1234 %define api.push-pull "push"
1235
1236 can be rewritten as
1237
1238 %define api.push-pull push
1239
1240 *** Unrecognized variables are now errors not warnings.
1241
1242 *** Multiple invocations for any variable is now an error not a warning.
1243
1244 ** Unrecognized %code qualifiers are now errors not warnings.
1245
1246 ** Character literals not of length one:
1247
1248 Previously, Bison quietly converted all character literals to length
1249 one. For example, without warning, Bison interpreted the operators in
1250 the following grammar to be the same token:
1251
1252 exp: exp '++'
1253 | exp '+' exp
1254 ;
1255
1256 Bison now warns when a character literal is not of length one. In
1257 some future release, Bison will start reporting an error instead.
1258
1259 ** Destructor calls fixed for lookaheads altered in semantic actions:
1260
1261 Previously for deterministic parsers in C, if a user semantic action
1262 altered yychar, the parser in some cases used the old yychar value to
1263 determine which destructor to call for the lookahead upon a syntax
1264 error or upon parser return. This bug has been fixed.
1265
1266 ** C++ parsers use YYRHSLOC:
1267
1268 Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
1269 macro and use it in the default YYLLOC_DEFAULT. You are encouraged
1270 to use it. If, for instance, your location structure has "first"
1271 and "last" members, instead of
1272
1273 # define YYLLOC_DEFAULT(Current, Rhs, N) \
1274 do \
1275 if (N) \
1276 { \
1277 (Current).first = (Rhs)[1].location.first; \
1278 (Current).last = (Rhs)[N].location.last; \
1279 } \
1280 else \
1281 { \
1282 (Current).first = (Current).last = (Rhs)[0].location.last; \
1283 } \
1284 while (false)
1285
1286 use:
1287
1288 # define YYLLOC_DEFAULT(Current, Rhs, N) \
1289 do \
1290 if (N) \
1291 { \
1292 (Current).first = YYRHSLOC (Rhs, 1).first; \
1293 (Current).last = YYRHSLOC (Rhs, N).last; \
1294 } \
1295 else \
1296 { \
1297 (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last; \
1298 } \
1299 while (false)
1300
1301 ** YYLLOC_DEFAULT in C++:
1302
1303 The default implementation of YYLLOC_DEFAULT used to be issued in
1304 the header file. It is now output in the implementation file, after
1305 the user %code sections so that its #ifndef guard does not try to
1306 override the user's YYLLOC_DEFAULT if provided.
1307
1308 ** YYFAIL now produces warnings and Java parsers no longer implement it:
1309
1310 YYFAIL has existed for many years as an undocumented feature of
1311 deterministic parsers in C generated by Bison. More recently, it was
1312 a documented feature of Bison's experimental Java parsers. As
1313 promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
1314 semantic action now produces a deprecation warning, and Java parsers
1315 no longer implement YYFAIL at all. For further details, including a
1316 discussion of how to suppress C preprocessor warnings about YYFAIL
1317 being unused, see the Bison 2.4.2 NEWS entry.
1318
1319 ** Temporary hack for adding a semicolon to the user action:
1320
1321 Previously, Bison appended a semicolon to every user action for
1322 reductions when the output language defaulted to C (specifically, when
1323 neither %yacc, %language, %skeleton, or equivalent command-line
1324 options were specified). This allowed actions such as
1325
1326 exp: exp "+" exp { $$ = $1 + $3 };
1327
1328 instead of
1329
1330 exp: exp "+" exp { $$ = $1 + $3; };
1331
1332 As a first step in removing this misfeature, Bison now issues a
1333 warning when it appends a semicolon. Moreover, in cases where Bison
1334 cannot easily determine whether a semicolon is needed (for example, an
1335 action ending with a cpp directive or a braced compound initializer),
1336 it no longer appends one. Thus, the C compiler might now complain
1337 about a missing semicolon where it did not before. Future releases of
1338 Bison will cease to append semicolons entirely.
1339
1340 ** Verbose syntax error message fixes:
1341
1342 When %error-verbose or the obsolete "#define YYERROR_VERBOSE" is
1343 specified, syntax error messages produced by the generated parser
1344 include the unexpected token as well as a list of expected tokens.
1345 The effect of %nonassoc on these verbose messages has been corrected
1346 in two ways, but a more complete fix requires LAC, described above:
1347
1348 *** When %nonassoc is used, there can exist parser states that accept no
1349 tokens, and so the parser does not always require a lookahead token
1350 in order to detect a syntax error. Because no unexpected token or
1351 expected tokens can then be reported, the verbose syntax error
1352 message described above is suppressed, and the parser instead
1353 reports the simpler message, "syntax error". Previously, this
1354 suppression was sometimes erroneously triggered by %nonassoc when a
1355 lookahead was actually required. Now verbose messages are
1356 suppressed only when all previous lookaheads have already been
1357 shifted or discarded.
1358
1359 *** Previously, the list of expected tokens erroneously included tokens
1360 that would actually induce a syntax error because conflicts for them
1361 were resolved with %nonassoc in the current parser state. Such
1362 tokens are now properly omitted from the list.
1363
1364 *** Expected token lists are still often wrong due to state merging
1365 (from LALR or IELR) and default reductions, which can both add
1366 invalid tokens and subtract valid tokens. Canonical LR almost
1367 completely fixes this problem by eliminating state merging and
1368 default reductions. However, there is one minor problem left even
1369 when using canonical LR and even after the fixes above. That is,
1370 if the resolution of a conflict with %nonassoc appears in a later
1371 parser state than the one at which some syntax error is
1372 discovered, the conflicted token is still erroneously included in
1373 the expected token list. Bison's new LAC implementation,
1374 described above, eliminates this problem and the need for
1375 canonical LR. However, LAC is still experimental and is disabled
1376 by default.
1377
1378 ** Java skeleton fixes:
1379
1380 *** A location handling bug has been fixed.
1381
1382 *** The top element of each of the value stack and location stack is now
1383 cleared when popped so that it can be garbage collected.
1384
1385 *** Parser traces now print the top element of the stack.
1386
1387 ** -W/--warnings fixes:
1388
1389 *** Bison now properly recognizes the "no-" versions of categories:
1390
1391 For example, given the following command line, Bison now enables all
1392 warnings except warnings for incompatibilities with POSIX Yacc:
1393
1394 bison -Wall,no-yacc gram.y
1395
1396 *** Bison now treats S/R and R/R conflicts like other warnings:
1397
1398 Previously, conflict reports were independent of Bison's normal
1399 warning system. Now, Bison recognizes the warning categories
1400 "conflicts-sr" and "conflicts-rr". This change has important
1401 consequences for the -W and --warnings command-line options. For
1402 example:
1403
1404 bison -Wno-conflicts-sr gram.y # S/R conflicts not reported
1405 bison -Wno-conflicts-rr gram.y # R/R conflicts not reported
1406 bison -Wnone gram.y # no conflicts are reported
1407 bison -Werror gram.y # any conflict is an error
1408
1409 However, as before, if the %expect or %expect-rr directive is
1410 specified, an unexpected number of conflicts is an error, and an
1411 expected number of conflicts is not reported, so -W and --warning
1412 then have no effect on the conflict report.
1413
1414 *** The "none" category no longer disables a preceding "error":
1415
1416 For example, for the following command line, Bison now reports
1417 errors instead of warnings for incompatibilities with POSIX Yacc:
1418
1419 bison -Werror,none,yacc gram.y
1420
1421 *** The "none" category now disables all Bison warnings:
1422
1423 Previously, the "none" category disabled only Bison warnings for
1424 which there existed a specific -W/--warning category. However,
1425 given the following command line, Bison is now guaranteed to
1426 suppress all warnings:
1427
1428 bison -Wnone gram.y
1429
1430 ** Precedence directives can now assign token number 0:
1431
1432 Since Bison 2.3b, which restored the ability of precedence
1433 directives to assign token numbers, doing so for token number 0 has
1434 produced an assertion failure. For example:
1435
1436 %left END 0
1437
1438 This bug has been fixed.
1439
1440 * Changes in version 2.4.3 (2010-08-05):
1441
1442 ** Bison now obeys -Werror and --warnings=error for warnings about
1443 grammar rules that are useless in the parser due to conflicts.
1444
1445 ** Problems with spawning M4 on at least FreeBSD 8 and FreeBSD 9 have
1446 been fixed.
1447
1448 ** Failures in the test suite for GCC 4.5 have been fixed.
1449
1450 ** Failures in the test suite for some versions of Sun Studio C++ have
1451 been fixed.
1452
1453 ** Contrary to Bison 2.4.2's NEWS entry, it has been decided that
1454 warnings about undefined %prec identifiers will not be converted to
1455 errors in Bison 2.5. They will remain warnings, which should be
1456 sufficient for POSIX while avoiding backward compatibility issues.
1457
1458 ** Minor documentation fixes.
1459
1460 * Changes in version 2.4.2 (2010-03-20):
1461
1462 ** Some portability problems that resulted in failures and livelocks
1463 in the test suite on some versions of at least Solaris, AIX, HP-UX,
1464 RHEL4, and Tru64 have been addressed. As a result, fatal Bison
1465 errors should no longer cause M4 to report a broken pipe on the
1466 affected platforms.
1467
1468 ** "%prec IDENTIFIER" requires IDENTIFIER to be defined separately.
1469
1470 POSIX specifies that an error be reported for any identifier that does
1471 not appear on the LHS of a grammar rule and that is not defined by
1472 %token, %left, %right, or %nonassoc. Bison 2.3b and later lost this
1473 error report for the case when an identifier appears only after a
1474 %prec directive. It is now restored. However, for backward
1475 compatibility with recent Bison releases, it is only a warning for
1476 now. In Bison 2.5 and later, it will return to being an error.
1477 [Between the 2.4.2 and 2.4.3 releases, it was decided that this
1478 warning will not be converted to an error in Bison 2.5.]
1479
1480 ** Detection of GNU M4 1.4.6 or newer during configure is improved.
1481
1482 ** Warnings from gcc's -Wundef option about undefined YYENABLE_NLS,
1483 YYLTYPE_IS_TRIVIAL, and __STRICT_ANSI__ in C/C++ parsers are now
1484 avoided.
1485
1486 ** %code is now a permanent feature.
1487
1488 A traditional Yacc prologue directive is written in the form:
1489
1490 %{CODE%}
1491
1492 To provide a more flexible alternative, Bison 2.3b introduced the
1493 %code directive with the following forms for C/C++:
1494
1495 %code {CODE}
1496 %code requires {CODE}
1497 %code provides {CODE}
1498 %code top {CODE}
1499
1500 These forms are now considered permanent features of Bison. See the
1501 %code entries in the section "Bison Declaration Summary" in the Bison
1502 manual for a summary of their functionality. See the section
1503 "Prologue Alternatives" for a detailed discussion including the
1504 advantages of %code over the traditional Yacc prologue directive.
1505
1506 Bison's Java feature as a whole including its current usage of %code
1507 is still considered experimental.
1508
1509 ** YYFAIL is deprecated and will eventually be removed.
1510
1511 YYFAIL has existed for many years as an undocumented feature of
1512 deterministic parsers in C generated by Bison. Previously, it was
1513 documented for Bison's experimental Java parsers. YYFAIL is no longer
1514 documented for Java parsers and is formally deprecated in both cases.
1515 Users are strongly encouraged to migrate to YYERROR, which is
1516 specified by POSIX.
1517
1518 Like YYERROR, you can invoke YYFAIL from a semantic action in order to
1519 induce a syntax error. The most obvious difference from YYERROR is
1520 that YYFAIL will automatically invoke yyerror to report the syntax
1521 error so that you don't have to. However, there are several other
1522 subtle differences between YYERROR and YYFAIL, and YYFAIL suffers from
1523 inherent flaws when %error-verbose or "#define YYERROR_VERBOSE" is
1524 used. For a more detailed discussion, see:
1525
1526 http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html
1527
1528 The upcoming Bison 2.5 will remove YYFAIL from Java parsers, but
1529 deterministic parsers in C will continue to implement it. However,
1530 because YYFAIL is already flawed, it seems futile to try to make new
1531 Bison features compatible with it. Thus, during parser generation,
1532 Bison 2.5 will produce a warning whenever it discovers YYFAIL in a
1533 rule action. In a later release, YYFAIL will be disabled for
1534 %error-verbose and "#define YYERROR_VERBOSE". Eventually, YYFAIL will
1535 be removed altogether.
1536
1537 There exists at least one case where Bison 2.5's YYFAIL warning will
1538 be a false positive. Some projects add phony uses of YYFAIL and other
1539 Bison-defined macros for the sole purpose of suppressing C
1540 preprocessor warnings (from GCC cpp's -Wunused-macros, for example).
1541 To avoid Bison's future warning, such YYFAIL uses can be moved to the
1542 epilogue (that is, after the second "%%") in the Bison input file. In
1543 this release (2.4.2), Bison already generates its own code to suppress
1544 C preprocessor warnings for YYFAIL, so projects can remove their own
1545 phony uses of YYFAIL if compatibility with Bison releases prior to
1546 2.4.2 is not necessary.
1547
1548 ** Internationalization.
1549
1550 Fix a regression introduced in Bison 2.4: Under some circumstances,
1551 message translations were not installed although supported by the
1552 host system.
1553
1554 * Changes in version 2.4.1 (2008-12-11):
1555
1556 ** In the GLR defines file, unexpanded M4 macros in the yylval and yylloc
1557 declarations have been fixed.
1558
1559 ** Temporary hack for adding a semicolon to the user action.
1560
1561 Bison used to prepend a trailing semicolon at the end of the user
1562 action for reductions. This allowed actions such as
1563
1564 exp: exp "+" exp { $$ = $1 + $3 };
1565
1566 instead of
1567
1568 exp: exp "+" exp { $$ = $1 + $3; };
1569
1570 Some grammars still depend on this "feature". Bison 2.4.1 restores
1571 the previous behavior in the case of C output (specifically, when
1572 neither %language or %skeleton or equivalent command-line options
1573 are used) to leave more time for grammars depending on the old
1574 behavior to be adjusted. Future releases of Bison will disable this
1575 feature.
1576
1577 ** A few minor improvements to the Bison manual.
1578
1579 * Changes in version 2.4 (2008-11-02):
1580
1581 ** %language is an experimental feature.
1582
1583 We first introduced this feature in test release 2.3b as a cleaner
1584 alternative to %skeleton. Since then, we have discussed the possibility of
1585 modifying its effect on Bison's output file names. Thus, in this release,
1586 we consider %language to be an experimental feature that will likely evolve
1587 in future releases.
1588
1589 ** Forward compatibility with GNU M4 has been improved.
1590
1591 ** Several bugs in the C++ skeleton and the experimental Java skeleton have been
1592 fixed.
1593
1594 * Changes in version 2.3b (2008-05-27):
1595
1596 ** The quotes around NAME that used to be required in the following directive
1597 are now deprecated:
1598
1599 %define NAME "VALUE"
1600
1601 ** The directive "%pure-parser" is now deprecated in favor of:
1602
1603 %define api.pure
1604
1605 which has the same effect except that Bison is more careful to warn about
1606 unreasonable usage in the latter case.
1607
1608 ** Push Parsing
1609
1610 Bison can now generate an LALR(1) parser in C with a push interface. That
1611 is, instead of invoking "yyparse", which pulls tokens from "yylex", you can
1612 push one token at a time to the parser using "yypush_parse", which will
1613 return to the caller after processing each token. By default, the push
1614 interface is disabled. Either of the following directives will enable it:
1615
1616 %define api.push_pull "push" // Just push; does not require yylex.
1617 %define api.push_pull "both" // Push and pull; requires yylex.
1618
1619 See the new section "A Push Parser" in the Bison manual for details.
1620
1621 The current push parsing interface is experimental and may evolve. More user
1622 feedback will help to stabilize it.
1623
1624 ** The -g and --graph options now output graphs in Graphviz DOT format,
1625 not VCG format. Like --graph, -g now also takes an optional FILE argument
1626 and thus cannot be bundled with other short options.
1627
1628 ** Java
1629
1630 Bison can now generate an LALR(1) parser in Java. The skeleton is
1631 "data/lalr1.java". Consider using the new %language directive instead of
1632 %skeleton to select it.
1633
1634 See the new section "Java Parsers" in the Bison manual for details.
1635
1636 The current Java interface is experimental and may evolve. More user
1637 feedback will help to stabilize it.
1638 Contributed by Paolo Bonzini.
1639
1640 ** %language
1641
1642 This new directive specifies the programming language of the generated
1643 parser, which can be C (the default), C++, or Java. Besides the skeleton
1644 that Bison uses, the directive affects the names of the generated files if
1645 the grammar file's name ends in ".y".
1646
1647 ** XML Automaton Report
1648
1649 Bison can now generate an XML report of the LALR(1) automaton using the new
1650 "--xml" option. The current XML schema is experimental and may evolve. More
1651 user feedback will help to stabilize it.
1652 Contributed by Wojciech Polak.
1653
1654 ** The grammar file may now specify the name of the parser header file using
1655 %defines. For example:
1656
1657 %defines "parser.h"
1658
1659 ** When reporting useless rules, useless nonterminals, and unused terminals,
1660 Bison now employs the terms "useless in grammar" instead of "useless",
1661 "useless in parser" instead of "never reduced", and "unused in grammar"
1662 instead of "unused".
1663
1664 ** Unreachable State Removal
1665
1666 Previously, Bison sometimes generated parser tables containing unreachable
1667 states. A state can become unreachable during conflict resolution if Bison
1668 disables a shift action leading to it from a predecessor state. Bison now:
1669
1670 1. Removes unreachable states.
1671
1672 2. Does not report any conflicts that appeared in unreachable states.
1673 WARNING: As a result, you may need to update %expect and %expect-rr
1674 directives in existing grammar files.
1675
1676 3. For any rule used only in such states, Bison now reports the rule as
1677 "useless in parser due to conflicts".
1678
1679 This feature can be disabled with the following directive:
1680
1681 %define lr.keep_unreachable_states
1682
1683 See the %define entry in the "Bison Declaration Summary" in the Bison manual
1684 for further discussion.
1685
1686 ** Lookahead Set Correction in the ".output" Report
1687
1688 When instructed to generate a ".output" file including lookahead sets
1689 (using "--report=lookahead", for example), Bison now prints each reduction's
1690 lookahead set only next to the associated state's one item that (1) is
1691 associated with the same rule as the reduction and (2) has its dot at the end
1692 of its RHS. Previously, Bison also erroneously printed the lookahead set
1693 next to all of the state's other items associated with the same rule. This
1694 bug affected only the ".output" file and not the generated parser source
1695 code.
1696
1697 ** --report-file=FILE is a new option to override the default ".output" file
1698 name.
1699
1700 ** The "=" that used to be required in the following directives is now
1701 deprecated:
1702
1703 %file-prefix "parser"
1704 %name-prefix "c_"
1705 %output "parser.c"
1706
1707 ** An Alternative to "%{...%}" -- "%code QUALIFIER {CODE}"
1708
1709 Bison 2.3a provided a new set of directives as a more flexible alternative to
1710 the traditional Yacc prologue blocks. Those have now been consolidated into
1711 a single %code directive with an optional qualifier field, which identifies
1712 the purpose of the code and thus the location(s) where Bison should generate
1713 it:
1714
1715 1. "%code {CODE}" replaces "%after-header {CODE}"
1716 2. "%code requires {CODE}" replaces "%start-header {CODE}"
1717 3. "%code provides {CODE}" replaces "%end-header {CODE}"
1718 4. "%code top {CODE}" replaces "%before-header {CODE}"
1719
1720 See the %code entries in section "Bison Declaration Summary" in the Bison
1721 manual for a summary of the new functionality. See the new section "Prologue
1722 Alternatives" for a detailed discussion including the advantages of %code
1723 over the traditional Yacc prologues.
1724
1725 The prologue alternatives are experimental. More user feedback will help to
1726 determine whether they should become permanent features.
1727
1728 ** Revised warning: unset or unused mid-rule values
1729
1730 Since Bison 2.2, Bison has warned about mid-rule values that are set but not
1731 used within any of the actions of the parent rule. For example, Bison warns
1732 about unused $2 in:
1733
1734 exp: '1' { $$ = 1; } '+' exp { $$ = $1 + $4; };
1735
1736 Now, Bison also warns about mid-rule values that are used but not set. For
1737 example, Bison warns about unset $$ in the mid-rule action in:
1738
1739 exp: '1' { $1 = 1; } '+' exp { $$ = $2 + $4; };
1740
1741 However, Bison now disables both of these warnings by default since they
1742 sometimes prove to be false alarms in existing grammars employing the Yacc
1743 constructs $0 or $-N (where N is some positive integer).
1744
1745 To enable these warnings, specify the option "--warnings=midrule-values" or
1746 "-W", which is a synonym for "--warnings=all".
1747
1748 ** Default %destructor or %printer with "<*>" or "<>"
1749
1750 Bison now recognizes two separate kinds of default %destructor's and
1751 %printer's:
1752
1753 1. Place "<*>" in a %destructor/%printer symbol list to define a default
1754 %destructor/%printer for all grammar symbols for which you have formally
1755 declared semantic type tags.
1756
1757 2. Place "<>" in a %destructor/%printer symbol list to define a default
1758 %destructor/%printer for all grammar symbols without declared semantic
1759 type tags.
1760
1761 Bison no longer supports the "%symbol-default" notation from Bison 2.3a.
1762 "<*>" and "<>" combined achieve the same effect with one exception: Bison no
1763 longer applies any %destructor to a mid-rule value if that mid-rule value is
1764 not actually ever referenced using either $$ or $n in a semantic action.
1765
1766 The default %destructor's and %printer's are experimental. More user
1767 feedback will help to determine whether they should become permanent
1768 features.
1769
1770 See the section "Freeing Discarded Symbols" in the Bison manual for further
1771 details.
1772
1773 ** %left, %right, and %nonassoc can now declare token numbers. This is required
1774 by POSIX. However, see the end of section "Operator Precedence" in the Bison
1775 manual for a caveat concerning the treatment of literal strings.
1776
1777 ** The nonfunctional --no-parser, -n, and %no-parser options have been
1778 completely removed from Bison.
1779
1780 * Changes in version 2.3a, 2006-09-13:
1781
1782 ** Instead of %union, you can define and use your own union type
1783 YYSTYPE if your grammar contains at least one <type> tag.
1784 Your YYSTYPE need not be a macro; it can be a typedef.
1785 This change is for compatibility with other Yacc implementations,
1786 and is required by POSIX.
1787
1788 ** Locations columns and lines start at 1.
1789 In accordance with the GNU Coding Standards and Emacs.
1790
1791 ** You may now declare per-type and default %destructor's and %printer's:
1792
1793 For example:
1794
1795 %union { char *string; }
1796 %token <string> STRING1
1797 %token <string> STRING2
1798 %type <string> string1
1799 %type <string> string2
1800 %union { char character; }
1801 %token <character> CHR
1802 %type <character> chr
1803 %destructor { free ($$); } %symbol-default
1804 %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
1805 %destructor { } <character>
1806
1807 guarantees that, when the parser discards any user-defined symbol that has a
1808 semantic type tag other than "<character>", it passes its semantic value to
1809 "free". However, when the parser discards a "STRING1" or a "string1", it
1810 also prints its line number to "stdout". It performs only the second
1811 "%destructor" in this case, so it invokes "free" only once.
1812
1813 [Although we failed to mention this here in the 2.3a release, the default
1814 %destructor's and %printer's were experimental, and they were rewritten in
1815 future versions.]
1816
1817 ** Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with "-y",
1818 "--yacc", or "%yacc"), Bison no longer generates #define statements for
1819 associating token numbers with token names. Removing the #define statements
1820 helps to sanitize the global namespace during preprocessing, but POSIX Yacc
1821 requires them. Bison still generates an enum for token names in all cases.
1822
1823 ** Handling of traditional Yacc prologue blocks is now more consistent but
1824 potentially incompatible with previous releases of Bison.
1825
1826 As before, you declare prologue blocks in your grammar file with the
1827 "%{ ... %}" syntax. To generate the pre-prologue, Bison concatenates all
1828 prologue blocks that you've declared before the first %union. To generate
1829 the post-prologue, Bison concatenates all prologue blocks that you've
1830 declared after the first %union.
1831
1832 Previous releases of Bison inserted the pre-prologue into both the header
1833 file and the code file in all cases except for LALR(1) parsers in C. In the
1834 latter case, Bison inserted it only into the code file. For parsers in C++,
1835 the point of insertion was before any token definitions (which associate
1836 token numbers with names). For parsers in C, the point of insertion was
1837 after the token definitions.
1838
1839 Now, Bison never inserts the pre-prologue into the header file. In the code
1840 file, it always inserts it before the token definitions.
1841
1842 ** Bison now provides a more flexible alternative to the traditional Yacc
1843 prologue blocks: %before-header, %start-header, %end-header, and
1844 %after-header.
1845
1846 For example, the following declaration order in the grammar file reflects the
1847 order in which Bison will output these code blocks. However, you are free to
1848 declare these code blocks in your grammar file in whatever order is most
1849 convenient for you:
1850
1851 %before-header {
1852 /* Bison treats this block like a pre-prologue block: it inserts it into
1853 * the code file before the contents of the header file. It does *not*
1854 * insert it into the header file. This is a good place to put
1855 * #include's that you want at the top of your code file. A common
1856 * example is '#include "system.h"'. */
1857 }
1858 %start-header {
1859 /* Bison inserts this block into both the header file and the code file.
1860 * In both files, the point of insertion is before any Bison-generated
1861 * token, semantic type, location type, and class definitions. This is a
1862 * good place to define %union dependencies, for example. */
1863 }
1864 %union {
1865 /* Unlike the traditional Yacc prologue blocks, the output order for the
1866 * new %*-header blocks is not affected by their declaration position
1867 * relative to any %union in the grammar file. */
1868 }
1869 %end-header {
1870 /* Bison inserts this block into both the header file and the code file.
1871 * In both files, the point of insertion is after the Bison-generated
1872 * definitions. This is a good place to declare or define public
1873 * functions or data structures that depend on the Bison-generated
1874 * definitions. */
1875 }
1876 %after-header {
1877 /* Bison treats this block like a post-prologue block: it inserts it into
1878 * the code file after the contents of the header file. It does *not*
1879 * insert it into the header file. This is a good place to declare or
1880 * define internal functions or data structures that depend on the
1881 * Bison-generated definitions. */
1882 }
1883
1884 If you have multiple occurrences of any one of the above declarations, Bison
1885 will concatenate the contents in declaration order.
1886
1887 [Although we failed to mention this here in the 2.3a release, the prologue
1888 alternatives were experimental, and they were rewritten in future versions.]
1889
1890 ** The option "--report=look-ahead" has been changed to "--report=lookahead".
1891 The old spelling still works, but is not documented and may be removed
1892 in a future release.
1893
1894 * Changes in version 2.3, 2006-06-05:
1895
1896 ** GLR grammars should now use "YYRECOVERING ()" instead of "YYRECOVERING",
1897 for compatibility with LALR(1) grammars.
1898
1899 ** It is now documented that any definition of YYSTYPE or YYLTYPE should
1900 be to a type name that does not contain parentheses or brackets.
1901
1902 * Changes in version 2.2, 2006-05-19:
1903
1904 ** The distribution terms for all Bison-generated parsers now permit
1905 using the parsers in nonfree programs. Previously, this permission
1906 was granted only for Bison-generated LALR(1) parsers in C.
1907
1908 ** %name-prefix changes the namespace name in C++ outputs.
1909
1910 ** The C++ parsers export their token_type.
1911
1912 ** Bison now allows multiple %union declarations, and concatenates
1913 their contents together.
1914
1915 ** New warning: unused values
1916 Right-hand side symbols whose values are not used are reported,
1917 if the symbols have destructors. For instance:
1918
1919 exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
1920 | exp "+" exp
1921 ;
1922
1923 will trigger a warning about $$ and $5 in the first rule, and $3 in
1924 the second ($1 is copied to $$ by the default rule). This example
1925 most likely contains three errors, and could be rewritten as:
1926
1927 exp: exp "?" exp ":" exp
1928 { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
1929 | exp "+" exp
1930 { $$ = $1 ? $1 : $3; if ($1) free ($3); }
1931 ;
1932
1933 However, if the original actions were really intended, memory leaks
1934 and all, the warnings can be suppressed by letting Bison believe the
1935 values are used, e.g.:
1936
1937 exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
1938 | exp "+" exp { $$ = $1; (void) $3; }
1939 ;
1940
1941 If there are mid-rule actions, the warning is issued if no action
1942 uses it. The following triggers no warning: $1 and $3 are used.
1943
1944 exp: exp { push ($1); } '+' exp { push ($3); sum (); };
1945
1946 The warning is intended to help catching lost values and memory leaks.
1947 If a value is ignored, its associated memory typically is not reclaimed.
1948
1949 ** %destructor vs. YYABORT, YYACCEPT, and YYERROR.
1950 Destructors are now called when user code invokes YYABORT, YYACCEPT,
1951 and YYERROR, for all objects on the stack, other than objects
1952 corresponding to the right-hand side of the current rule.
1953
1954 ** %expect, %expect-rr
1955 Incorrect numbers of expected conflicts are now actual errors,
1956 instead of warnings.
1957
1958 ** GLR, YACC parsers.
1959 The %parse-params are available in the destructors (and the
1960 experimental printers) as per the documentation.
1961
1962 ** Bison now warns if it finds a stray "$" or "@" in an action.
1963
1964 ** %require "VERSION"
1965 This specifies that the grammar file depends on features implemented
1966 in Bison version VERSION or higher.
1967
1968 ** lalr1.cc: The token and value types are now class members.
1969 The tokens were defined as free form enums and cpp macros. YYSTYPE
1970 was defined as a free form union. They are now class members:
1971 tokens are enumerations of the "yy::parser::token" struct, and the
1972 semantic values have the "yy::parser::semantic_type" type.
1973
1974 If you do not want or can update to this scheme, the directive
1975 '%define "global_tokens_and_yystype" "1"' triggers the global
1976 definition of tokens and YYSTYPE. This change is suitable both
1977 for previous releases of Bison, and this one.
1978
1979 If you wish to update, then make sure older version of Bison will
1980 fail using '%require "2.2"'.
1981
1982 ** DJGPP support added.
1983 \f
1984 * Changes in version 2.1, 2005-09-16:
1985
1986 ** The C++ lalr1.cc skeleton supports %lex-param.
1987
1988 ** Bison-generated parsers now support the translation of diagnostics like
1989 "syntax error" into languages other than English. The default
1990 language is still English. For details, please see the new
1991 Internationalization section of the Bison manual. Software
1992 distributors should also see the new PACKAGING file. Thanks to
1993 Bruno Haible for this new feature.
1994
1995 ** Wording in the Bison-generated parsers has been changed slightly to
1996 simplify translation. In particular, the message "memory exhausted"
1997 has replaced "parser stack overflow", as the old message was not
1998 always accurate for modern Bison-generated parsers.
1999
2000 ** Destructors are now called when the parser aborts, for all symbols left
2001 behind on the stack. Also, the start symbol is now destroyed after a
2002 successful parse. In both cases, the behavior was formerly inconsistent.
2003
2004 ** When generating verbose diagnostics, Bison-generated parsers no longer
2005 quote the literal strings associated with tokens. For example, for
2006 a syntax error associated with '%token NUM "number"' they might
2007 print 'syntax error, unexpected number' instead of 'syntax error,
2008 unexpected "number"'.
2009 \f
2010 * Changes in version 2.0, 2004-12-25:
2011
2012 ** Possibly-incompatible changes
2013
2014 - Bison-generated parsers no longer default to using the alloca function
2015 (when available) to extend the parser stack, due to widespread
2016 problems in unchecked stack-overflow detection. You can "#define
2017 YYSTACK_USE_ALLOCA 1" to require the use of alloca, but please read
2018 the manual to determine safe values for YYMAXDEPTH in that case.
2019
2020 - Error token location.
2021 During error recovery, the location of the syntax error is updated
2022 to cover the whole sequence covered by the error token: it includes
2023 the shifted symbols thrown away during the first part of the error
2024 recovery, and the lookahead rejected during the second part.
2025
2026 - Semicolon changes:
2027 . Stray semicolons are no longer allowed at the start of a grammar.
2028 . Semicolons are now required after in-grammar declarations.
2029
2030 - Unescaped newlines are no longer allowed in character constants or
2031 string literals. They were never portable, and GCC 3.4.0 has
2032 dropped support for them. Better diagnostics are now generated if
2033 forget a closing quote.
2034
2035 - NUL bytes are no longer allowed in Bison string literals, unfortunately.
2036
2037 ** New features
2038
2039 - GLR grammars now support locations.
2040
2041 - New directive: %initial-action.
2042 This directive allows the user to run arbitrary code (including
2043 initializing @$) from yyparse before parsing starts.
2044
2045 - A new directive "%expect-rr N" specifies the expected number of
2046 reduce/reduce conflicts in GLR parsers.
2047
2048 - %token numbers can now be hexadecimal integers, e.g., "%token FOO 0x12d".
2049 This is a GNU extension.
2050
2051 - The option "--report=lookahead" was changed to "--report=look-ahead".
2052 [However, this was changed back after 2.3.]
2053
2054 - Experimental %destructor support has been added to lalr1.cc.
2055
2056 - New configure option --disable-yacc, to disable installation of the
2057 yacc command and -ly library introduced in 1.875 for POSIX conformance.
2058
2059 ** Bug fixes
2060
2061 - For now, %expect-count violations are now just warnings, not errors.
2062 This is for compatibility with Bison 1.75 and earlier (when there are
2063 reduce/reduce conflicts) and with Bison 1.30 and earlier (when there
2064 are too many or too few shift/reduce conflicts). However, in future
2065 versions of Bison we plan to improve the %expect machinery so that
2066 these violations will become errors again.
2067
2068 - Within Bison itself, numbers (e.g., goto numbers) are no longer
2069 arbitrarily limited to 16-bit counts.
2070
2071 - Semicolons are now allowed before "|" in grammar rules, as POSIX requires.
2072 \f
2073 * Changes in version 1.875, 2003-01-01:
2074
2075 ** The documentation license has been upgraded to version 1.2
2076 of the GNU Free Documentation License.
2077
2078 ** syntax error processing
2079
2080 - In Yacc-style parsers YYLLOC_DEFAULT is now used to compute error
2081 locations too. This fixes bugs in error-location computation.
2082
2083 - %destructor
2084 It is now possible to reclaim the memory associated to symbols
2085 discarded during error recovery. This feature is still experimental.
2086
2087 - %error-verbose
2088 This new directive is preferred over YYERROR_VERBOSE.
2089
2090 - #defining yyerror to steal internal variables is discouraged.
2091 It is not guaranteed to work forever.
2092
2093 ** POSIX conformance
2094
2095 - Semicolons are once again optional at the end of grammar rules.
2096 This reverts to the behavior of Bison 1.33 and earlier, and improves
2097 compatibility with Yacc.
2098
2099 - "parse error" -> "syntax error"
2100 Bison now uniformly uses the term "syntax error"; formerly, the code
2101 and manual sometimes used the term "parse error" instead. POSIX
2102 requires "syntax error" in diagnostics, and it was thought better to
2103 be consistent.
2104
2105 - The documentation now emphasizes that yylex and yyerror must be
2106 declared before use. C99 requires this.
2107
2108 - Bison now parses C99 lexical constructs like UCNs and
2109 backslash-newline within C escape sequences, as POSIX 1003.1-2001 requires.
2110
2111 - File names are properly escaped in C output. E.g., foo\bar.y is
2112 output as "foo\\bar.y".
2113
2114 - Yacc command and library now available
2115 The Bison distribution now installs a "yacc" command, as POSIX requires.
2116 Also, Bison now installs a small library liby.a containing
2117 implementations of Yacc-compatible yyerror and main functions.
2118 This library is normally not useful, but POSIX requires it.
2119
2120 - Type clashes now generate warnings, not errors.
2121
2122 - If the user does not define YYSTYPE as a macro, Bison now declares it
2123 using typedef instead of defining it as a macro.
2124 For consistency, YYLTYPE is also declared instead of defined.
2125
2126 ** Other compatibility issues
2127
2128 - %union directives can now have a tag before the "{", e.g., the
2129 directive "%union foo {...}" now generates the C code
2130 "typedef union foo { ... } YYSTYPE;"; this is for Yacc compatibility.
2131 The default union tag is "YYSTYPE", for compatibility with Solaris 9 Yacc.
2132 For consistency, YYLTYPE's struct tag is now "YYLTYPE" not "yyltype".
2133 This is for compatibility with both Yacc and Bison 1.35.
2134
2135 - ";" is output before the terminating "}" of an action, for
2136 compatibility with Bison 1.35.
2137
2138 - Bison now uses a Yacc-style format for conflict reports, e.g.,
2139 "conflicts: 2 shift/reduce, 1 reduce/reduce".
2140
2141 - "yystype" and "yyltype" are now obsolescent macros instead of being
2142 typedefs or tags; they are no longer documented and are planned to be
2143 withdrawn in a future release.
2144
2145 ** GLR parser notes
2146
2147 - GLR and inline
2148 Users of Bison have to decide how they handle the portability of the
2149 C keyword "inline".
2150
2151 - "parsing stack overflow..." -> "parser stack overflow"
2152 GLR parsers now report "parser stack overflow" as per the Bison manual.
2153
2154 ** %parse-param and %lex-param
2155 The macros YYPARSE_PARAM and YYLEX_PARAM provide a means to pass
2156 additional context to yyparse and yylex. They suffer from several
2157 shortcomings:
2158
2159 - a single argument only can be added,
2160 - their types are weak (void *),
2161 - this context is not passed to ancillary functions such as yyerror,
2162 - only yacc.c parsers support them.
2163
2164 The new %parse-param/%lex-param directives provide a more precise control.
2165 For instance:
2166
2167 %parse-param {int *nastiness}
2168 %lex-param {int *nastiness}
2169 %parse-param {int *randomness}
2170
2171 results in the following signatures:
2172
2173 int yylex (int *nastiness);
2174 int yyparse (int *nastiness, int *randomness);
2175
2176 or, if both %pure-parser and %locations are used:
2177
2178 int yylex (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
2179 int yyparse (int *nastiness, int *randomness);
2180
2181 ** Bison now warns if it detects conflicting outputs to the same file,
2182 e.g., it generates a warning for "bison -d -o foo.h foo.y" since
2183 that command outputs both code and header to foo.h.
2184
2185 ** #line in output files
2186 - --no-line works properly.
2187
2188 ** Bison can no longer be built by a K&R C compiler; it requires C89 or
2189 later to be built. This change originally took place a few versions
2190 ago, but nobody noticed until we recently asked someone to try
2191 building Bison with a K&R C compiler.
2192 \f
2193 * Changes in version 1.75, 2002-10-14:
2194
2195 ** Bison should now work on 64-bit hosts.
2196
2197 ** Indonesian translation thanks to Tedi Heriyanto.
2198
2199 ** GLR parsers
2200 Fix spurious parse errors.
2201
2202 ** Pure parsers
2203 Some people redefine yyerror to steal yyparse' private variables.
2204 Reenable this trick until an official feature replaces it.
2205
2206 ** Type Clashes
2207 In agreement with POSIX and with other Yaccs, leaving a default
2208 action is valid when $$ is untyped, and $1 typed:
2209
2210 untyped: ... typed;
2211
2212 but the converse remains an error:
2213
2214 typed: ... untyped;
2215
2216 ** Values of mid-rule actions
2217 The following code:
2218
2219 foo: { ... } { $$ = $1; } ...
2220
2221 was incorrectly rejected: $1 is defined in the second mid-rule
2222 action, and is equal to the $$ of the first mid-rule action.
2223 \f
2224 * Changes in version 1.50, 2002-10-04:
2225
2226 ** GLR parsing
2227 The declaration
2228 %glr-parser
2229 causes Bison to produce a Generalized LR (GLR) parser, capable of handling
2230 almost any context-free grammar, ambiguous or not. The new declarations
2231 %dprec and %merge on grammar rules allow parse-time resolution of
2232 ambiguities. Contributed by Paul Hilfinger.
2233
2234 Unfortunately Bison 1.50 does not work properly on 64-bit hosts
2235 like the Alpha, so please stick to 32-bit hosts for now.
2236
2237 ** Output Directory
2238 When not in Yacc compatibility mode, when the output file was not
2239 specified, running "bison foo/bar.y" created "foo/bar.c". It
2240 now creates "bar.c".
2241
2242 ** Undefined token
2243 The undefined token was systematically mapped to 2 which prevented
2244 the use of 2 by the user. This is no longer the case.
2245
2246 ** Unknown token numbers
2247 If yylex returned an out of range value, yyparse could die. This is
2248 no longer the case.
2249
2250 ** Error token
2251 According to POSIX, the error token must be 256.
2252 Bison extends this requirement by making it a preference: *if* the
2253 user specified that one of her tokens is numbered 256, then error
2254 will be mapped onto another number.
2255
2256 ** Verbose error messages
2257 They no longer report "..., expecting error or..." for states where
2258 error recovery is possible.
2259
2260 ** End token
2261 Defaults to "$end" instead of "$".
2262
2263 ** Error recovery now conforms to documentation and to POSIX
2264 When a Bison-generated parser encounters a syntax error, it now pops
2265 the stack until it finds a state that allows shifting the error
2266 token. Formerly, it popped the stack until it found a state that
2267 allowed some non-error action other than a default reduction on the
2268 error token. The new behavior has long been the documented behavior,
2269 and has long been required by POSIX. For more details, please see
2270 Paul Eggert, "Reductions during Bison error handling" (2002-05-20)
2271 <http://lists.gnu.org/archive/html/bug-bison/2002-05/msg00038.html>.
2272
2273 ** Traces
2274 Popped tokens and nonterminals are now reported.
2275
2276 ** Larger grammars
2277 Larger grammars are now supported (larger token numbers, larger grammar
2278 size (= sum of the LHS and RHS lengths), larger LALR tables).
2279 Formerly, many of these numbers ran afoul of 16-bit limits;
2280 now these limits are 32 bits on most hosts.
2281
2282 ** Explicit initial rule
2283 Bison used to play hacks with the initial rule, which the user does
2284 not write. It is now explicit, and visible in the reports and
2285 graphs as rule 0.
2286
2287 ** Useless rules
2288 Before, Bison reported the useless rules, but, although not used,
2289 included them in the parsers. They are now actually removed.
2290
2291 ** Useless rules, useless nonterminals
2292 They are now reported, as a warning, with their locations.
2293
2294 ** Rules never reduced
2295 Rules that can never be reduced because of conflicts are now
2296 reported.
2297
2298 ** Incorrect "Token not used"
2299 On a grammar such as
2300
2301 %token useless useful
2302 %%
2303 exp: '0' %prec useful;
2304
2305 where a token was used to set the precedence of the last rule,
2306 bison reported both "useful" and "useless" as useless tokens.
2307
2308 ** Revert the C++ namespace changes introduced in 1.31
2309 as they caused too many portability hassles.
2310
2311 ** Default locations
2312 By an accident of design, the default computation of @$ was
2313 performed after another default computation was performed: @$ = @1.
2314 The latter is now removed: YYLLOC_DEFAULT is fully responsible of
2315 the computation of @$.
2316
2317 ** Token end-of-file
2318 The token end of file may be specified by the user, in which case,
2319 the user symbol is used in the reports, the graphs, and the verbose
2320 error messages instead of "$end", which remains being the default.
2321 For instance
2322 %token MYEOF 0
2323 or
2324 %token MYEOF 0 "end of file"
2325
2326 ** Semantic parser
2327 This old option, which has been broken for ages, is removed.
2328
2329 ** New translations
2330 Brazilian Portuguese, thanks to Alexandre Folle de Menezes.
2331 Croatian, thanks to Denis Lackovic.
2332
2333 ** Incorrect token definitions
2334 When given
2335 %token 'a' "A"
2336 bison used to output
2337 #define 'a' 65
2338
2339 ** Token definitions as enums
2340 Tokens are output both as the traditional #define's, and, provided
2341 the compiler supports ANSI C or is a C++ compiler, as enums.
2342 This lets debuggers display names instead of integers.
2343
2344 ** Reports
2345 In addition to --verbose, bison supports --report=THINGS, which
2346 produces additional information:
2347 - itemset
2348 complete the core item sets with their closure
2349 - lookahead [changed to "look-ahead" in 1.875e through 2.3, but changed back]
2350 explicitly associate lookahead tokens to items
2351 - solved
2352 describe shift/reduce conflicts solving.
2353 Bison used to systematically output this information on top of
2354 the report. Solved conflicts are now attached to their states.
2355
2356 ** Type clashes
2357 Previous versions don't complain when there is a type clash on
2358 the default action if the rule has a mid-rule action, such as in:
2359
2360 %type <foo> bar
2361 %%
2362 bar: '0' {} '0';
2363
2364 This is fixed.
2365
2366 ** GNU M4 is now required when using Bison.
2367 \f
2368 * Changes in version 1.35, 2002-03-25:
2369
2370 ** C Skeleton
2371 Some projects use Bison's C parser with C++ compilers, and define
2372 YYSTYPE as a class. The recent adjustment of C parsers for data
2373 alignment and 64 bit architectures made this impossible.
2374
2375 Because for the time being no real solution for C++ parser
2376 generation exists, kludges were implemented in the parser to
2377 maintain this use. In the future, when Bison has C++ parsers, this
2378 kludge will be disabled.
2379
2380 This kludge also addresses some C++ problems when the stack was
2381 extended.
2382 \f
2383 * Changes in version 1.34, 2002-03-12:
2384
2385 ** File name clashes are detected
2386 $ bison foo.y -d -o foo.x
2387 fatal error: header and parser would both be named "foo.x"
2388
2389 ** A missing ";" at the end of a rule triggers a warning
2390 In accordance with POSIX, and in agreement with other
2391 Yacc implementations, Bison will mandate this semicolon in the near
2392 future. This eases the implementation of a Bison parser of Bison
2393 grammars by making this grammar LALR(1) instead of LR(2). To
2394 facilitate the transition, this release introduces a warning.
2395
2396 ** Revert the C++ namespace changes introduced in 1.31, as they caused too
2397 many portability hassles.
2398
2399 ** DJGPP support added.
2400
2401 ** Fix test suite portability problems.
2402 \f
2403 * Changes in version 1.33, 2002-02-07:
2404
2405 ** Fix C++ issues
2406 Groff could not be compiled for the definition of size_t was lacking
2407 under some conditions.
2408
2409 ** Catch invalid @n
2410 As is done with $n.
2411 \f
2412 * Changes in version 1.32, 2002-01-23:
2413
2414 ** Fix Yacc output file names
2415
2416 ** Portability fixes
2417
2418 ** Italian, Dutch translations
2419 \f
2420 * Changes in version 1.31, 2002-01-14:
2421
2422 ** Many Bug Fixes
2423
2424 ** GNU Gettext and %expect
2425 GNU Gettext asserts 10 s/r conflicts, but there are 7. Now that
2426 Bison dies on incorrect %expectations, we fear there will be
2427 too many bug reports for Gettext, so _for the time being_, %expect
2428 does not trigger an error when the input file is named "plural.y".
2429
2430 ** Use of alloca in parsers
2431 If YYSTACK_USE_ALLOCA is defined to 0, then the parsers will use
2432 malloc exclusively. Since 1.29, but was not NEWS'ed.
2433
2434 alloca is used only when compiled with GCC, to avoid portability
2435 problems as on AIX.
2436
2437 ** yyparse now returns 2 if memory is exhausted; formerly it dumped core.
2438
2439 ** When the generated parser lacks debugging code, YYDEBUG is now 0
2440 (as POSIX requires) instead of being undefined.
2441
2442 ** User Actions
2443 Bison has always permitted actions such as { $$ = $1 }: it adds the
2444 ending semicolon. Now if in Yacc compatibility mode, the semicolon
2445 is no longer output: one has to write { $$ = $1; }.
2446
2447 ** Better C++ compliance
2448 The output parsers try to respect C++ namespaces.
2449 [This turned out to be a failed experiment, and it was reverted later.]
2450
2451 ** Reduced Grammars
2452 Fixed bugs when reporting useless nonterminals.
2453
2454 ** 64 bit hosts
2455 The parsers work properly on 64 bit hosts.
2456
2457 ** Error messages
2458 Some calls to strerror resulted in scrambled or missing error messages.
2459
2460 ** %expect
2461 When the number of shift/reduce conflicts is correct, don't issue
2462 any warning.
2463
2464 ** The verbose report includes the rule line numbers.
2465
2466 ** Rule line numbers are fixed in traces.
2467
2468 ** Swedish translation
2469
2470 ** Parse errors
2471 Verbose parse error messages from the parsers are better looking.
2472 Before: parse error: unexpected `'/'', expecting `"number"' or `'-'' or `'(''
2473 Now: parse error: unexpected '/', expecting "number" or '-' or '('
2474
2475 ** Fixed parser memory leaks.
2476 When the generated parser was using malloc to extend its stacks, the
2477 previous allocations were not freed.
2478
2479 ** Fixed verbose output file.
2480 Some newlines were missing.
2481 Some conflicts in state descriptions were missing.
2482
2483 ** Fixed conflict report.
2484 Option -v was needed to get the result.
2485
2486 ** %expect
2487 Was not used.
2488 Mismatches are errors, not warnings.
2489
2490 ** Fixed incorrect processing of some invalid input.
2491
2492 ** Fixed CPP guards: 9foo.h uses BISON_9FOO_H instead of 9FOO_H.
2493
2494 ** Fixed some typos in the documentation.
2495
2496 ** %token MY_EOF 0 is supported.
2497 Before, MY_EOF was silently renumbered as 257.
2498
2499 ** doc/refcard.tex is updated.
2500
2501 ** %output, %file-prefix, %name-prefix.
2502 New.
2503
2504 ** --output
2505 New, aliasing "--output-file".
2506 \f
2507 * Changes in version 1.30, 2001-10-26:
2508
2509 ** "--defines" and "--graph" have now an optional argument which is the
2510 output file name. "-d" and "-g" do not change; they do not take any
2511 argument.
2512
2513 ** "%source_extension" and "%header_extension" are removed, failed
2514 experiment.
2515
2516 ** Portability fixes.
2517 \f
2518 * Changes in version 1.29, 2001-09-07:
2519
2520 ** The output file does not define const, as this caused problems when used
2521 with common autoconfiguration schemes. If you still use ancient compilers
2522 that lack const, compile with the equivalent of the C compiler option
2523 "-Dconst=". Autoconf's AC_C_CONST macro provides one way to do this.
2524
2525 ** Added "-g" and "--graph".
2526
2527 ** The Bison manual is now distributed under the terms of the GNU FDL.
2528
2529 ** The input and the output files has automatically a similar extension.
2530
2531 ** Russian translation added.
2532
2533 ** NLS support updated; should hopefully be less troublesome.
2534
2535 ** Added the old Bison reference card.
2536
2537 ** Added "--locations" and "%locations".
2538
2539 ** Added "-S" and "--skeleton".
2540
2541 ** "%raw", "-r", "--raw" is disabled.
2542
2543 ** Special characters are escaped when output. This solves the problems
2544 of the #line lines with path names including backslashes.
2545
2546 ** New directives.
2547 "%yacc", "%fixed_output_files", "%defines", "%no_parser", "%verbose",
2548 "%debug", "%source_extension" and "%header_extension".
2549
2550 ** @$
2551 Automatic location tracking.
2552 \f
2553 * Changes in version 1.28, 1999-07-06:
2554
2555 ** Should compile better now with K&R compilers.
2556
2557 ** Added NLS.
2558
2559 ** Fixed a problem with escaping the double quote character.
2560
2561 ** There is now a FAQ.
2562 \f
2563 * Changes in version 1.27:
2564
2565 ** The make rule which prevented bison.simple from being created on
2566 some systems has been fixed.
2567 \f
2568 * Changes in version 1.26:
2569
2570 ** Bison now uses Automake.
2571
2572 ** New mailing lists: <bug-bison@gnu.org> and <help-bison@gnu.org>.
2573
2574 ** Token numbers now start at 257 as previously documented, not 258.
2575
2576 ** Bison honors the TMPDIR environment variable.
2577
2578 ** A couple of buffer overruns have been fixed.
2579
2580 ** Problems when closing files should now be reported.
2581
2582 ** Generated parsers should now work even on operating systems which do
2583 not provide alloca().
2584 \f
2585 * Changes in version 1.25, 1995-10-16:
2586
2587 ** Errors in the input grammar are not fatal; Bison keeps reading
2588 the grammar file, and reports all the errors found in it.
2589
2590 ** Tokens can now be specified as multiple-character strings: for
2591 example, you could use "<=" for a token which looks like <=, instead
2592 of choosing a name like LESSEQ.
2593
2594 ** The %token_table declaration says to write a table of tokens (names
2595 and numbers) into the parser file. The yylex function can use this
2596 table to recognize multiple-character string tokens, or for other
2597 purposes.
2598
2599 ** The %no_lines declaration says not to generate any #line preprocessor
2600 directives in the parser file.
2601
2602 ** The %raw declaration says to use internal Bison token numbers, not
2603 Yacc-compatible token numbers, when token names are defined as macros.
2604
2605 ** The --no-parser option produces the parser tables without including
2606 the parser engine; a project can now use its own parser engine.
2607 The actions go into a separate file called NAME.act, in the form of
2608 a switch statement body.
2609 \f
2610 * Changes in version 1.23:
2611
2612 The user can define YYPARSE_PARAM as the name of an argument to be
2613 passed into yyparse. The argument should have type void *. It should
2614 actually point to an object. Grammar actions can access the variable
2615 by casting it to the proper pointer type.
2616
2617 Line numbers in output file corrected.
2618 \f
2619 * Changes in version 1.22:
2620
2621 --help option added.
2622 \f
2623 * Changes in version 1.20:
2624
2625 Output file does not redefine const for C++.
2626
2627 -----
2628
2629 Copyright (C) 1995-2013 Free Software Foundation, Inc.
2630
2631 This file is part of Bison, the GNU Parser Generator.
2632
2633 This program is free software: you can redistribute it and/or modify
2634 it under the terms of the GNU General Public License as published by
2635 the Free Software Foundation, either version 3 of the License, or
2636 (at your option) any later version.
2637
2638 This program is distributed in the hope that it will be useful,
2639 but WITHOUT ANY WARRANTY; without even the implied warranty of
2640 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
2641 GNU General Public License for more details.
2642
2643 You should have received a copy of the GNU General Public License
2644 along with this program. If not, see <http://www.gnu.org/licenses/>.
2645
2646 LocalWords: yacc YYBACKUP glr GCC lalr ArrayIndexOutOfBoundsException nullptr
2647 LocalWords: cplusplus liby rpl fprintf mfcalc Wyacc stmt cond expr mk sym lr
2648 LocalWords: IELR ielr Lookahead YYERROR nonassoc LALR's api lookaheads yychar
2649 LocalWords: destructor lookahead YYRHSLOC YYLLOC Rhs ifndef YYFAIL cpp sr rr
2650 LocalWords: preprocessor initializer Wno Wnone Werror FreeBSD prec livelocks
2651 LocalWords: Solaris AIX UX RHEL Tru LHS gcc's Wundef YYENABLE NLS YYLTYPE VCG
2652 LocalWords: yyerror cpp's Wunused yylval yylloc prepend yyparse yylex yypush
2653 LocalWords: Graphviz xml nonterminals midrule destructor's YYSTYPE typedef ly
2654 LocalWords: CHR chr printf stdout namespace preprocessing enum pre include's
2655 LocalWords: YYRECOVERING nonfree destructors YYABORT YYACCEPT params enums de
2656 LocalWords: struct yystype DJGPP lex param Haible NUM alloca YYSTACK NUL goto
2657 LocalWords: YYMAXDEPTH Unescaped UCNs YYLTYPE's yyltype typedefs inline Yaccs
2658 LocalWords: Heriyanto Reenable dprec Hilfinger Eggert MYEOF Folle Menezes EOF
2659 LocalWords: Lackovic define's itemset Groff Gettext malloc NEWS'ed YYDEBUG YY
2660 LocalWords: namespaces strerror const autoconfiguration Dconst Autoconf's FDL
2661 LocalWords: Automake TMPDIR LESSEQ ylwrap endif yydebug YYTOKEN YYLSP ival hh
2662 LocalWords: extern YYTOKENTYPE TOKENTYPE yytokentype tokentype STYPE lval pdf
2663 LocalWords: lang yyoutput dvi html ps POSIX lvalp llocp Wother nterm arg init
2664 LocalWords: TOK calc yyo fval Wconflicts parsers yystackp yyval yynerrs
2665 LocalWords: Théophile Ranquet Santet fno fnone stype associativity Tolmer
2666 LocalWords: Wprecedence Rassoul Wempty Paolo Bonzini parser's Michiel loc
2667 LocalWords: redeclaration sval fcaret reentrant XSLT xsl Wmaybe yyvsp Tedi
2668 LocalWords: pragmas noreturn untyped Rozenman unexpanded Wojciech Polak
2669 LocalWords: Alexandre MERCHANTABILITY yytype
2670
2671 Local Variables:
2672 mode: outline
2673 fill-column: 76
2674 End: