]> git.saurik.com Git - bison.git/blame_incremental - NEWS
* doc/bison.texinfo (Prologue Alternatives): Fix a tiny typo.
[bison.git] / NEWS
... / ...
CommitLineData
1Bison News
2----------
3
4Changes in version 2.3a+ (????-??-??):
5
6* The -g and --graph options now output graphs in Graphviz DOT format,
7 not VCG format.
8
9* The Yacc prologue alternatives from Bison 2.3a have been rewritten as the
10 following directives:
11
12 1. %code {CODE}
13
14 Other than semantic actions, this is probably the most common place you
15 should write verbatim code for the parser implementation. For C/C++, it
16 replaces the traditional Yacc prologue, `%{CODE%}', for most purposes.
17 For Java, it inserts your CODE into the parser class. Compare with:
18
19 - `%{CODE%}' appearing after the first `%union {CODE}' in a C/C++
20 based grammar file. While Bison will continue to support `%{CODE%}'
21 for backward compatibility, `%code {CODE}' is cleaner as its
22 functionality does not depend on its position in the grammar file
23 relative to any `%union {CODE}'. Specifically, `%code {CODE}'
24 always inserts your CODE into the parser code file after the usual
25 contents of the parser header file.
26 - `%after-header {CODE}', which only Bison 2.3a supported.
27
28 2. %requires {CODE}
29
30 This is the right place to write dependency code for externally exposed
31 definitions required by Bison. For C/C++, such exposed definitions are
32 those usually appearing in the parser header file. Thus, this is the
33 right place to define types referenced in `%union {CODE}' directives,
34 and it is the right place to override Bison's default YYSTYPE and
35 YYLTYPE definitions. For Java, this is the right place to write import
36 directives. Compare with:
37
38 - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
39 based grammar file. Unlike `%{CODE%}', `%requires {CODE}' inserts
40 your CODE both into the parser code file and into the parser header
41 file since Bison's required definitions should depend on it in both
42 places.
43 - `%start-header {CODE}', which only Bison 2.3a supported.
44
45 3. %provides {CODE}
46
47 This is the right place to write additional definitions you would like
48 Bison to expose externally. For C/C++, this directive inserts your CODE
49 both into the parser header file and into the parser code file after
50 Bison's required definitions. For Java, it inserts your CODE into the
51 parser java file after the parser class. Compare with:
52
53 - `%end-header {CODE}', which only Bison 2.3a supported.
54
55 4. %code-top {CODE}
56
57 Occasionally for C/C++ it is desirable to insert code near the top of
58 the parser code file. For example:
59
60 %code-top {
61 #define _GNU_SOURCE
62 #include <stdio.h>
63 }
64
65 For Java, `%code-top {CODE}' is currently unused. Compare with:
66
67 - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++
68 based grammar file. `%code-top {CODE}' is cleaner as its
69 functionality does not depend on its position in the grammar file
70 relative to any `%union {CODE}'.
71 - `%before-header {CODE}', which only Bison 2.3a supported.
72
73 If you have multiple occurrences of any one of the above four directives,
74 Bison will concatenate the contents in the order they appear in the grammar
75 file.
76
77Changes in version 2.3a, 2006-09-13:
78
79* Instead of %union, you can define and use your own union type
80 YYSTYPE if your grammar contains at least one <type> tag.
81 Your YYSTYPE need not be a macro; it can be a typedef.
82 This change is for compatibility with other Yacc implementations,
83 and is required by POSIX.
84
85* Locations columns and lines start at 1.
86 In accordance with the GNU Coding Standards and Emacs.
87
88* You may now declare per-type and default %destructor's and %printer's:
89
90 For example:
91
92 %union { char *string; }
93 %token <string> STRING1
94 %token <string> STRING2
95 %type <string> string1
96 %type <string> string2
97 %union { char character; }
98 %token <character> CHR
99 %type <character> chr
100 %destructor { free ($$); } %symbol-default
101 %destructor { free ($$); printf ("%d", @$.first_line); } STRING1 string1
102 %destructor { } <character>
103
104 guarantees that, when the parser discards any user-defined symbol that has a
105 semantic type tag other than `<character>', it passes its semantic value to
106 `free'. However, when the parser discards a `STRING1' or a `string1', it
107 also prints its line number to `stdout'. It performs only the second
108 `%destructor' in this case, so it invokes `free' only once.
109
110* Except for LALR(1) parsers in C with POSIX Yacc emulation enabled (with `-y',
111 `--yacc', or `%yacc'), Bison no longer generates #define statements for
112 associating token numbers with token names. Removing the #define statements
113 helps to sanitize the global namespace during preprocessing, but POSIX Yacc
114 requires them. Bison still generates an enum for token names in all cases.
115
116* Handling of traditional Yacc prologue blocks is now more consistent but
117 potentially incompatible with previous releases of Bison.
118
119 As before, you declare prologue blocks in your grammar file with the
120 `%{ ... %}' syntax. To generate the pre-prologue, Bison concatenates all
121 prologue blocks that you've declared before the first %union. To generate
122 the post-prologue, Bison concatenates all prologue blocks that you've
123 declared after the first %union.
124
125 Previous releases of Bison inserted the pre-prologue into both the header
126 file and the code file in all cases except for LALR(1) parsers in C. In the
127 latter case, Bison inserted it only into the code file. For parsers in C++,
128 the point of insertion was before any token definitions (which associate
129 token numbers with names). For parsers in C, the point of insertion was
130 after the token definitions.
131
132 Now, Bison never inserts the pre-prologue into the header file. In the code
133 file, it always inserts it before the token definitions.
134
135* Bison now provides a more flexible alternative to the traditional Yacc
136 prologue blocks: %before-header, %start-header, %end-header, and
137 %after-header.
138
139 For example, the following declaration order in the grammar file reflects the
140 order in which Bison will output these code blocks. However, you are free to
141 declare these code blocks in your grammar file in whatever order is most
142 convenient for you:
143
144 %before-header {
145 /* Bison treats this block like a pre-prologue block: it inserts it into
146 * the code file before the contents of the header file. It does *not*
147 * insert it into the header file. This is a good place to put
148 * #include's that you want at the top of your code file. A common
149 * example is `#include "system.h"'. */
150 }
151 %start-header {
152 /* Bison inserts this block into both the header file and the code file.
153 * In both files, the point of insertion is before any Bison-generated
154 * token, semantic type, location type, and class definitions. This is a
155 * good place to define %union dependencies, for example. */
156 }
157 %union {
158 /* Unlike the traditional Yacc prologue blocks, the output order for the
159 * new %*-header blocks is not affected by their declaration position
160 * relative to any %union in the grammar file. */
161 }
162 %end-header {
163 /* Bison inserts this block into both the header file and the code file.
164 * In both files, the point of insertion is after the Bison-generated
165 * definitions. This is a good place to declare or define public
166 * functions or data structures that depend on the Bison-generated
167 * definitions. */
168 }
169 %after-header {
170 /* Bison treats this block like a post-prologue block: it inserts it into
171 * the code file after the contents of the header file. It does *not*
172 * insert it into the header file. This is a good place to declare or
173 * define internal functions or data structures that depend on the
174 * Bison-generated definitions. */
175 }
176
177 If you have multiple occurrences of any one of the above declarations, Bison
178 will concatenate the contents in declaration order.
179
180* The option `--report=look-ahead' has been changed to `--report=lookahead'.
181 The old spelling still works, but is not documented and may be removed
182 in a future release.
183
184Changes in version 2.3, 2006-06-05:
185
186* GLR grammars should now use `YYRECOVERING ()' instead of `YYRECOVERING',
187 for compatibility with LALR(1) grammars.
188
189* It is now documented that any definition of YYSTYPE or YYLTYPE should
190 be to a type name that does not contain parentheses or brackets.
191
192Changes in version 2.2, 2006-05-19:
193
194* The distribution terms for all Bison-generated parsers now permit
195 using the parsers in nonfree programs. Previously, this permission
196 was granted only for Bison-generated LALR(1) parsers in C.
197
198* %name-prefix changes the namespace name in C++ outputs.
199
200* The C++ parsers export their token_type.
201
202* Bison now allows multiple %union declarations, and concatenates
203 their contents together.
204
205* New warning: unused values
206 Right-hand side symbols whose values are not used are reported,
207 if the symbols have destructors. For instance:
208
209 exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
210 | exp "+" exp
211 ;
212
213 will trigger a warning about $$ and $5 in the first rule, and $3 in
214 the second ($1 is copied to $$ by the default rule). This example
215 most likely contains three errors, and could be rewritten as:
216
217 exp: exp "?" exp ":" exp
218 { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
219 | exp "+" exp
220 { $$ = $1 ? $1 : $3; if ($1) free ($3); }
221 ;
222
223 However, if the original actions were really intended, memory leaks
224 and all, the warnings can be suppressed by letting Bison believe the
225 values are used, e.g.:
226
227 exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
228 | exp "+" exp { $$ = $1; (void) $3; }
229 ;
230
231 If there are mid-rule actions, the warning is issued if no action
232 uses it. The following triggers no warning: $1 and $3 are used.
233
234 exp: exp { push ($1); } '+' exp { push ($3); sum (); };
235
236 The warning is intended to help catching lost values and memory leaks.
237 If a value is ignored, its associated memory typically is not reclaimed.
238
239* %destructor vs. YYABORT, YYACCEPT, and YYERROR.
240 Destructors are now called when user code invokes YYABORT, YYACCEPT,
241 and YYERROR, for all objects on the stack, other than objects
242 corresponding to the right-hand side of the current rule.
243
244* %expect, %expect-rr
245 Incorrect numbers of expected conflicts are now actual errors,
246 instead of warnings.
247
248* GLR, YACC parsers.
249 The %parse-params are available in the destructors (and the
250 experimental printers) as per the documentation.
251
252* Bison now warns if it finds a stray `$' or `@' in an action.
253
254* %require "VERSION"
255 This specifies that the grammar file depends on features implemented
256 in Bison version VERSION or higher.
257
258* lalr1.cc: The token and value types are now class members.
259 The tokens were defined as free form enums and cpp macros. YYSTYPE
260 was defined as a free form union. They are now class members:
261 tokens are enumerations of the `yy::parser::token' struct, and the
262 semantic values have the `yy::parser::semantic_type' type.
263
264 If you do not want or can update to this scheme, the directive
265 `%define "global_tokens_and_yystype" "1"' triggers the global
266 definition of tokens and YYSTYPE. This change is suitable both
267 for previous releases of Bison, and this one.
268
269 If you wish to update, then make sure older version of Bison will
270 fail using `%require "2.2"'.
271
272* DJGPP support added.
273\f
274Changes in version 2.1, 2005-09-16:
275
276* The C++ lalr1.cc skeleton supports %lex-param.
277
278* Bison-generated parsers now support the translation of diagnostics like
279 "syntax error" into languages other than English. The default
280 language is still English. For details, please see the new
281 Internationalization section of the Bison manual. Software
282 distributors should also see the new PACKAGING file. Thanks to
283 Bruno Haible for this new feature.
284
285* Wording in the Bison-generated parsers has been changed slightly to
286 simplify translation. In particular, the message "memory exhausted"
287 has replaced "parser stack overflow", as the old message was not
288 always accurate for modern Bison-generated parsers.
289
290* Destructors are now called when the parser aborts, for all symbols left
291 behind on the stack. Also, the start symbol is now destroyed after a
292 successful parse. In both cases, the behavior was formerly inconsistent.
293
294* When generating verbose diagnostics, Bison-generated parsers no longer
295 quote the literal strings associated with tokens. For example, for
296 a syntax error associated with '%token NUM "number"' they might
297 print 'syntax error, unexpected number' instead of 'syntax error,
298 unexpected "number"'.
299\f
300Changes in version 2.0, 2004-12-25:
301
302* Possibly-incompatible changes
303
304 - Bison-generated parsers no longer default to using the alloca function
305 (when available) to extend the parser stack, due to widespread
306 problems in unchecked stack-overflow detection. You can "#define
307 YYSTACK_USE_ALLOCA 1" to require the use of alloca, but please read
308 the manual to determine safe values for YYMAXDEPTH in that case.
309
310 - Error token location.
311 During error recovery, the location of the syntax error is updated
312 to cover the whole sequence covered by the error token: it includes
313 the shifted symbols thrown away during the first part of the error
314 recovery, and the lookahead rejected during the second part.
315
316 - Semicolon changes:
317 . Stray semicolons are no longer allowed at the start of a grammar.
318 . Semicolons are now required after in-grammar declarations.
319
320 - Unescaped newlines are no longer allowed in character constants or
321 string literals. They were never portable, and GCC 3.4.0 has
322 dropped support for them. Better diagnostics are now generated if
323 forget a closing quote.
324
325 - NUL bytes are no longer allowed in Bison string literals, unfortunately.
326
327* New features
328
329 - GLR grammars now support locations.
330
331 - New directive: %initial-action.
332 This directive allows the user to run arbitrary code (including
333 initializing @$) from yyparse before parsing starts.
334
335 - A new directive "%expect-rr N" specifies the expected number of
336 reduce/reduce conflicts in GLR parsers.
337
338 - %token numbers can now be hexadecimal integers, e.g., `%token FOO 0x12d'.
339 This is a GNU extension.
340
341 - The option `--report=lookahead' was changed to `--report=look-ahead'.
342 [However, this was changed back after 2.3.]
343
344 - Experimental %destructor support has been added to lalr1.cc.
345
346 - New configure option --disable-yacc, to disable installation of the
347 yacc command and -ly library introduced in 1.875 for POSIX conformance.
348
349* Bug fixes
350
351 - For now, %expect-count violations are now just warnings, not errors.
352 This is for compatibility with Bison 1.75 and earlier (when there are
353 reduce/reduce conflicts) and with Bison 1.30 and earlier (when there
354 are too many or too few shift/reduce conflicts). However, in future
355 versions of Bison we plan to improve the %expect machinery so that
356 these violations will become errors again.
357
358 - Within Bison itself, numbers (e.g., goto numbers) are no longer
359 arbitrarily limited to 16-bit counts.
360
361 - Semicolons are now allowed before "|" in grammar rules, as POSIX requires.
362\f
363Changes in version 1.875, 2003-01-01:
364
365* The documentation license has been upgraded to version 1.2
366 of the GNU Free Documentation License.
367
368* syntax error processing
369
370 - In Yacc-style parsers YYLLOC_DEFAULT is now used to compute error
371 locations too. This fixes bugs in error-location computation.
372
373 - %destructor
374 It is now possible to reclaim the memory associated to symbols
375 discarded during error recovery. This feature is still experimental.
376
377 - %error-verbose
378 This new directive is preferred over YYERROR_VERBOSE.
379
380 - #defining yyerror to steal internal variables is discouraged.
381 It is not guaranteed to work forever.
382
383* POSIX conformance
384
385 - Semicolons are once again optional at the end of grammar rules.
386 This reverts to the behavior of Bison 1.33 and earlier, and improves
387 compatibility with Yacc.
388
389 - `parse error' -> `syntax error'
390 Bison now uniformly uses the term `syntax error'; formerly, the code
391 and manual sometimes used the term `parse error' instead. POSIX
392 requires `syntax error' in diagnostics, and it was thought better to
393 be consistent.
394
395 - The documentation now emphasizes that yylex and yyerror must be
396 declared before use. C99 requires this.
397
398 - Bison now parses C99 lexical constructs like UCNs and
399 backslash-newline within C escape sequences, as POSIX 1003.1-2001 requires.
400
401 - File names are properly escaped in C output. E.g., foo\bar.y is
402 output as "foo\\bar.y".
403
404 - Yacc command and library now available
405 The Bison distribution now installs a `yacc' command, as POSIX requires.
406 Also, Bison now installs a small library liby.a containing
407 implementations of Yacc-compatible yyerror and main functions.
408 This library is normally not useful, but POSIX requires it.
409
410 - Type clashes now generate warnings, not errors.
411
412 - If the user does not define YYSTYPE as a macro, Bison now declares it
413 using typedef instead of defining it as a macro.
414 For consistency, YYLTYPE is also declared instead of defined.
415
416* Other compatibility issues
417
418 - %union directives can now have a tag before the `{', e.g., the
419 directive `%union foo {...}' now generates the C code
420 `typedef union foo { ... } YYSTYPE;'; this is for Yacc compatibility.
421 The default union tag is `YYSTYPE', for compatibility with Solaris 9 Yacc.
422 For consistency, YYLTYPE's struct tag is now `YYLTYPE' not `yyltype'.
423 This is for compatibility with both Yacc and Bison 1.35.
424
425 - `;' is output before the terminating `}' of an action, for
426 compatibility with Bison 1.35.
427
428 - Bison now uses a Yacc-style format for conflict reports, e.g.,
429 `conflicts: 2 shift/reduce, 1 reduce/reduce'.
430
431 - `yystype' and `yyltype' are now obsolescent macros instead of being
432 typedefs or tags; they are no longer documented and are planned to be
433 withdrawn in a future release.
434
435* GLR parser notes
436
437 - GLR and inline
438 Users of Bison have to decide how they handle the portability of the
439 C keyword `inline'.
440
441 - `parsing stack overflow...' -> `parser stack overflow'
442 GLR parsers now report `parser stack overflow' as per the Bison manual.
443
444* Bison now warns if it detects conflicting outputs to the same file,
445 e.g., it generates a warning for `bison -d -o foo.h foo.y' since
446 that command outputs both code and header to foo.h.
447
448* #line in output files
449 - --no-line works properly.
450
451* Bison can no longer be built by a K&R C compiler; it requires C89 or
452 later to be built. This change originally took place a few versions
453 ago, but nobody noticed until we recently asked someone to try
454 building Bison with a K&R C compiler.
455\f
456Changes in version 1.75, 2002-10-14:
457
458* Bison should now work on 64-bit hosts.
459
460* Indonesian translation thanks to Tedi Heriyanto.
461
462* GLR parsers
463 Fix spurious parse errors.
464
465* Pure parsers
466 Some people redefine yyerror to steal yyparse' private variables.
467 Reenable this trick until an official feature replaces it.
468
469* Type Clashes
470 In agreement with POSIX and with other Yaccs, leaving a default
471 action is valid when $$ is untyped, and $1 typed:
472
473 untyped: ... typed;
474
475 but the converse remains an error:
476
477 typed: ... untyped;
478
479* Values of mid-rule actions
480 The following code:
481
482 foo: { ... } { $$ = $1; } ...
483
484 was incorrectly rejected: $1 is defined in the second mid-rule
485 action, and is equal to the $$ of the first mid-rule action.
486\f
487Changes in version 1.50, 2002-10-04:
488
489* GLR parsing
490 The declaration
491 %glr-parser
492 causes Bison to produce a Generalized LR (GLR) parser, capable of handling
493 almost any context-free grammar, ambiguous or not. The new declarations
494 %dprec and %merge on grammar rules allow parse-time resolution of
495 ambiguities. Contributed by Paul Hilfinger.
496
497 Unfortunately Bison 1.50 does not work properly on 64-bit hosts
498 like the Alpha, so please stick to 32-bit hosts for now.
499
500* Output Directory
501 When not in Yacc compatibility mode, when the output file was not
502 specified, running `bison foo/bar.y' created `foo/bar.c'. It
503 now creates `bar.c'.
504
505* Undefined token
506 The undefined token was systematically mapped to 2 which prevented
507 the use of 2 by the user. This is no longer the case.
508
509* Unknown token numbers
510 If yylex returned an out of range value, yyparse could die. This is
511 no longer the case.
512
513* Error token
514 According to POSIX, the error token must be 256.
515 Bison extends this requirement by making it a preference: *if* the
516 user specified that one of her tokens is numbered 256, then error
517 will be mapped onto another number.
518
519* Verbose error messages
520 They no longer report `..., expecting error or...' for states where
521 error recovery is possible.
522
523* End token
524 Defaults to `$end' instead of `$'.
525
526* Error recovery now conforms to documentation and to POSIX
527 When a Bison-generated parser encounters a syntax error, it now pops
528 the stack until it finds a state that allows shifting the error
529 token. Formerly, it popped the stack until it found a state that
530 allowed some non-error action other than a default reduction on the
531 error token. The new behavior has long been the documented behavior,
532 and has long been required by POSIX. For more details, please see
533 Paul Eggert, "Reductions during Bison error handling" (2002-05-20)
534 <http://lists.gnu.org/archive/html/bug-bison/2002-05/msg00038.html>.
535
536* Traces
537 Popped tokens and nonterminals are now reported.
538
539* Larger grammars
540 Larger grammars are now supported (larger token numbers, larger grammar
541 size (= sum of the LHS and RHS lengths), larger LALR tables).
542 Formerly, many of these numbers ran afoul of 16-bit limits;
543 now these limits are 32 bits on most hosts.
544
545* Explicit initial rule
546 Bison used to play hacks with the initial rule, which the user does
547 not write. It is now explicit, and visible in the reports and
548 graphs as rule 0.
549
550* Useless rules
551 Before, Bison reported the useless rules, but, although not used,
552 included them in the parsers. They are now actually removed.
553
554* Useless rules, useless nonterminals
555 They are now reported, as a warning, with their locations.
556
557* Rules never reduced
558 Rules that can never be reduced because of conflicts are now
559 reported.
560
561* Incorrect `Token not used'
562 On a grammar such as
563
564 %token useless useful
565 %%
566 exp: '0' %prec useful;
567
568 where a token was used to set the precedence of the last rule,
569 bison reported both `useful' and `useless' as useless tokens.
570
571* Revert the C++ namespace changes introduced in 1.31
572 as they caused too many portability hassles.
573
574* Default locations
575 By an accident of design, the default computation of @$ was
576 performed after another default computation was performed: @$ = @1.
577 The latter is now removed: YYLLOC_DEFAULT is fully responsible of
578 the computation of @$.
579
580* Token end-of-file
581 The token end of file may be specified by the user, in which case,
582 the user symbol is used in the reports, the graphs, and the verbose
583 error messages instead of `$end', which remains being the default.
584 For instance
585 %token MYEOF 0
586 or
587 %token MYEOF 0 "end of file"
588
589* Semantic parser
590 This old option, which has been broken for ages, is removed.
591
592* New translations
593 Brazilian Portuguese, thanks to Alexandre Folle de Menezes.
594 Croatian, thanks to Denis Lackovic.
595
596* Incorrect token definitions
597 When given `%token 'a' "A"', Bison used to output `#define 'a' 65'.
598
599* Token definitions as enums
600 Tokens are output both as the traditional #define's, and, provided
601 the compiler supports ANSI C or is a C++ compiler, as enums.
602 This lets debuggers display names instead of integers.
603
604* Reports
605 In addition to --verbose, bison supports --report=THINGS, which
606 produces additional information:
607 - itemset
608 complete the core item sets with their closure
609 - lookahead [changed to `look-ahead' in 1.875e through 2.3, but changed back]
610 explicitly associate lookahead tokens to items
611 - solved
612 describe shift/reduce conflicts solving.
613 Bison used to systematically output this information on top of
614 the report. Solved conflicts are now attached to their states.
615
616* Type clashes
617 Previous versions don't complain when there is a type clash on
618 the default action if the rule has a mid-rule action, such as in:
619
620 %type <foo> bar
621 %%
622 bar: '0' {} '0';
623
624 This is fixed.
625
626* GNU M4 is now required when using Bison.
627\f
628Changes in version 1.35, 2002-03-25:
629
630* C Skeleton
631 Some projects use Bison's C parser with C++ compilers, and define
632 YYSTYPE as a class. The recent adjustment of C parsers for data
633 alignment and 64 bit architectures made this impossible.
634
635 Because for the time being no real solution for C++ parser
636 generation exists, kludges were implemented in the parser to
637 maintain this use. In the future, when Bison has C++ parsers, this
638 kludge will be disabled.
639
640 This kludge also addresses some C++ problems when the stack was
641 extended.
642\f
643Changes in version 1.34, 2002-03-12:
644
645* File name clashes are detected
646 $ bison foo.y -d -o foo.x
647 fatal error: header and parser would both be named `foo.x'
648
649* A missing `;' at the end of a rule triggers a warning
650 In accordance with POSIX, and in agreement with other
651 Yacc implementations, Bison will mandate this semicolon in the near
652 future. This eases the implementation of a Bison parser of Bison
653 grammars by making this grammar LALR(1) instead of LR(2). To
654 facilitate the transition, this release introduces a warning.
655
656* Revert the C++ namespace changes introduced in 1.31, as they caused too
657 many portability hassles.
658
659* DJGPP support added.
660
661* Fix test suite portability problems.
662\f
663Changes in version 1.33, 2002-02-07:
664
665* Fix C++ issues
666 Groff could not be compiled for the definition of size_t was lacking
667 under some conditions.
668
669* Catch invalid @n
670 As is done with $n.
671\f
672Changes in version 1.32, 2002-01-23:
673
674* Fix Yacc output file names
675
676* Portability fixes
677
678* Italian, Dutch translations
679\f
680Changes in version 1.31, 2002-01-14:
681
682* Many Bug Fixes
683
684* GNU Gettext and %expect
685 GNU Gettext asserts 10 s/r conflicts, but there are 7. Now that
686 Bison dies on incorrect %expectations, we fear there will be
687 too many bug reports for Gettext, so _for the time being_, %expect
688 does not trigger an error when the input file is named `plural.y'.
689
690* Use of alloca in parsers
691 If YYSTACK_USE_ALLOCA is defined to 0, then the parsers will use
692 malloc exclusively. Since 1.29, but was not NEWS'ed.
693
694 alloca is used only when compiled with GCC, to avoid portability
695 problems as on AIX.
696
697* yyparse now returns 2 if memory is exhausted; formerly it dumped core.
698
699* When the generated parser lacks debugging code, YYDEBUG is now 0
700 (as POSIX requires) instead of being undefined.
701
702* User Actions
703 Bison has always permitted actions such as { $$ = $1 }: it adds the
704 ending semicolon. Now if in Yacc compatibility mode, the semicolon
705 is no longer output: one has to write { $$ = $1; }.
706
707* Better C++ compliance
708 The output parsers try to respect C++ namespaces.
709 [This turned out to be a failed experiment, and it was reverted later.]
710
711* Reduced Grammars
712 Fixed bugs when reporting useless nonterminals.
713
714* 64 bit hosts
715 The parsers work properly on 64 bit hosts.
716
717* Error messages
718 Some calls to strerror resulted in scrambled or missing error messages.
719
720* %expect
721 When the number of shift/reduce conflicts is correct, don't issue
722 any warning.
723
724* The verbose report includes the rule line numbers.
725
726* Rule line numbers are fixed in traces.
727
728* Swedish translation
729
730* Parse errors
731 Verbose parse error messages from the parsers are better looking.
732 Before: parse error: unexpected `'/'', expecting `"number"' or `'-'' or `'(''
733 Now: parse error: unexpected '/', expecting "number" or '-' or '('
734
735* Fixed parser memory leaks.
736 When the generated parser was using malloc to extend its stacks, the
737 previous allocations were not freed.
738
739* Fixed verbose output file.
740 Some newlines were missing.
741 Some conflicts in state descriptions were missing.
742
743* Fixed conflict report.
744 Option -v was needed to get the result.
745
746* %expect
747 Was not used.
748 Mismatches are errors, not warnings.
749
750* Fixed incorrect processing of some invalid input.
751
752* Fixed CPP guards: 9foo.h uses BISON_9FOO_H instead of 9FOO_H.
753
754* Fixed some typos in the documentation.
755
756* %token MY_EOF 0 is supported.
757 Before, MY_EOF was silently renumbered as 257.
758
759* doc/refcard.tex is updated.
760
761* %output, %file-prefix, %name-prefix.
762 New.
763
764* --output
765 New, aliasing `--output-file'.
766\f
767Changes in version 1.30, 2001-10-26:
768
769* `--defines' and `--graph' have now an optional argument which is the
770 output file name. `-d' and `-g' do not change; they do not take any
771 argument.
772
773* `%source_extension' and `%header_extension' are removed, failed
774 experiment.
775
776* Portability fixes.
777\f
778Changes in version 1.29, 2001-09-07:
779
780* The output file does not define const, as this caused problems when used
781 with common autoconfiguration schemes. If you still use ancient compilers
782 that lack const, compile with the equivalent of the C compiler option
783 `-Dconst='. autoconf's AC_C_CONST macro provides one way to do this.
784
785* Added `-g' and `--graph'.
786
787* The Bison manual is now distributed under the terms of the GNU FDL.
788
789* The input and the output files has automatically a similar extension.
790
791* Russian translation added.
792
793* NLS support updated; should hopefully be less troublesome.
794
795* Added the old Bison reference card.
796
797* Added `--locations' and `%locations'.
798
799* Added `-S' and `--skeleton'.
800
801* `%raw', `-r', `--raw' is disabled.
802
803* Special characters are escaped when output. This solves the problems
804 of the #line lines with path names including backslashes.
805
806* New directives.
807 `%yacc', `%fixed_output_files', `%defines', `%no_parser', `%verbose',
808 `%debug', `%source_extension' and `%header_extension'.
809
810* @$
811 Automatic location tracking.
812\f
813Changes in version 1.28, 1999-07-06:
814
815* Should compile better now with K&R compilers.
816
817* Added NLS.
818
819* Fixed a problem with escaping the double quote character.
820
821* There is now a FAQ.
822\f
823Changes in version 1.27:
824
825* The make rule which prevented bison.simple from being created on
826 some systems has been fixed.
827\f
828Changes in version 1.26:
829
830* Bison now uses automake.
831
832* New mailing lists: <bug-bison@gnu.org> and <help-bison@gnu.org>.
833
834* Token numbers now start at 257 as previously documented, not 258.
835
836* Bison honors the TMPDIR environment variable.
837
838* A couple of buffer overruns have been fixed.
839
840* Problems when closing files should now be reported.
841
842* Generated parsers should now work even on operating systems which do
843 not provide alloca().
844\f
845Changes in version 1.25, 1995-10-16:
846
847* Errors in the input grammar are not fatal; Bison keeps reading
848the grammar file, and reports all the errors found in it.
849
850* Tokens can now be specified as multiple-character strings: for
851example, you could use "<=" for a token which looks like <=, instead
852of chosing a name like LESSEQ.
853
854* The %token_table declaration says to write a table of tokens (names
855and numbers) into the parser file. The yylex function can use this
856table to recognize multiple-character string tokens, or for other
857purposes.
858
859* The %no_lines declaration says not to generate any #line preprocessor
860directives in the parser file.
861
862* The %raw declaration says to use internal Bison token numbers, not
863Yacc-compatible token numbers, when token names are defined as macros.
864
865* The --no-parser option produces the parser tables without including
866the parser engine; a project can now use its own parser engine.
867The actions go into a separate file called NAME.act, in the form of
868a switch statement body.
869\f
870Changes in version 1.23:
871
872The user can define YYPARSE_PARAM as the name of an argument to be
873passed into yyparse. The argument should have type void *. It should
874actually point to an object. Grammar actions can access the variable
875by casting it to the proper pointer type.
876
877Line numbers in output file corrected.
878\f
879Changes in version 1.22:
880
881--help option added.
882\f
883Changes in version 1.20:
884
885Output file does not redefine const for C++.
886
887Local Variables:
888mode: outline
889End:
890
891-----
892
893Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
8942004, 2005, 2006 Free Software Foundation, Inc.
895
896This file is part of Bison, the GNU Compiler Compiler.
897
898Bison is free software; you can redistribute it and/or modify
899it under the terms of the GNU General Public License as published by
900the Free Software Foundation; either version 2, or (at your option)
901any later version.
902
903Bison is distributed in the hope that it will be useful,
904but WITHOUT ANY WARRANTY; without even the implied warranty of
905MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
906GNU General Public License for more details.
907
908You should have received a copy of the GNU General Public License
909along with autoconf; see the file COPYING. If not, write to
910the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
911Boston, MA 02110-1301, USA.