3 See the recent changes about function prototypes in POSIX Yacc. Implement
7 The default case is scanning char-per-char.
9 /* By default, grow the string obstack with the input. */
15 commit c22902e360e0fbbe9fd5657dcf107e03166da309
16 Author: Akim Demaille <akim.demaille@gmail.com>
17 Date: Sat Jan 23 18:40:15 2021 +0100
19 tables: fix handling for useless tokens
21 See https://github.com/akimd/bison/issues/72#issuecomment-766153154
23 commit 2c294c132528ede23d8ae4959783a67e9ff05ac5
24 Author: Vincent Imbimbo <vmi6@cornell.edu>
25 Date: Sat Jan 23 13:25:18 2021 -0500
27 cex: fix state-item pruning
29 See https://lists.gnu.org/r/bug-bison/2021-01/msg00002.html
32 The current approach is correct, but with poor performances. Bitsets need
33 to support 'assign' and 'shift'. And instead of extending POS_SET just for
34 the out-of-range new values, we need something like doubling the size.
37 There is no test with "Parse on stack %ld rejected by rule %d" in it.
40 Clarify that rule numbers in the skeletons are 1-based.
43 There are many macros that should obey api.prefix: YY_CPLUSPLUS, YY_MOVE,
47 And add tests in calc.at, to prepare work for D.
49 ** YYERROR and yynerrs
50 We are missing some cases. Write a test case, and check all the skeletons.
54 Don't do this (counterexample.c):
56 // This is the fastest way to get the tail node from the gl_list API.
58 list_get_end (gl_list_t list)
60 gl_list_node_t sentinel = gl_list_add_last (list, NULL);
61 gl_list_node_t res = gl_list_previous_node (list, sentinel);
62 gl_list_remove_node (list, sentinel);
66 *** Ambiguous rewriting
67 If the user is stupid enough to have equal rules, then the derivations are
70 Reduce/reduce conflict on tokens $end, "+", "⊕":
74 First derivation exp ::=[ exp "+" exp • ]
76 Second derivation exp ::=[ exp "+" exp • ]
78 Do we care about this? In color, we use twice the same color here, but we
79 could try to use the same color for the same rule.
82 Show the counterexamples. This is going to be really hard and/or painful.
83 Unless we play it dumb (little structure).
86 - How about not evaluating incomplete lines when the text is not finished
91 - Should i18n be part of the Lexer? Currently it's a static method of
94 - is there a migration path that would allow to use TokenKinds in
97 - define the tokens as an enum too.
99 - promote YYEOF rather than EOF.
102 https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-runtime/intl/plural.y;h=a712255af4f2f739c93336d4ff6556d932a426a5;hb=HEAD
104 should be updated to not use YYERRCODE. Returning an undef token is good
109 Stop hard-coding "Calc". Adjust local.at (look for FIXME).
111 ** A dev warning for b4_
112 Maybe we should check for m4_ and b4_ leaking out of the m4 processing, as
113 Autoconf does. It would have caught over-quotation issues.
116 I feel it's ugly to use the GNU style to declare functions in the doc. It
117 generates tons of white space in the page, and may contribute to bad page
124 The YYUNDEFTOK could be assigned a semantic value so that yyerror could be
125 used to report invalid lexemes.
128 Consider deprecating impure push parsers. They add a lot of complexity, for
129 a bad feature. On the other hand, that would make it much harder to sit
130 push parsers on top of pull parser. Which is currently not relevant, since
131 push parsers are measurably slower.
133 ** %define parse.error formatted
134 How about pushing Bistromathic's yyreport_syntax_error as another standard
135 way to generate the error message, and leave to the user the task of
136 providing the message formats? Currently in bistro, it reads:
139 error_format_string (int argc)
143 default: /* Avoid compiler warnings. */
144 case 0: return _("%@: syntax error");
145 case 1: return _("%@: syntax error: unexpected %u");
146 // TRANSLATORS: '%@' is a location in a file, '%u' is an
147 // "unexpected token", and '%0e', '%1e'... are expected tokens
150 // For instance on the expression "1 + * 2", you'd get
152 // 1.5: syntax error: expected - or ( or number or function or variable before *
153 case 2: return _("%@: syntax error: expected %0e before %u");
154 case 3: return _("%@: syntax error: expected %0e or %1e before %u");
155 case 4: return _("%@: syntax error: expected %0e or %1e or %2e before %u");
156 case 5: return _("%@: syntax error: expected %0e or %1e or %2e or %3e before %u");
157 case 6: return _("%@: syntax error: expected %0e or %1e or %2e or %3e or %4e before %u");
158 case 7: return _("%@: syntax error: expected %0e or %1e or %2e or %3e or %4e or %5e before %u");
159 case 8: return _("%@: syntax error: expected %0e or %1e or %2e or %3e or %4e or %5e or %6e before %u");
163 The message would have to be generated in a string, and pushed to yyerror.
164 Which will be a pain in the neck in yacc.c.
166 If we want to do that, we should think very carefully about the syntax of
169 ** yyclearin does not invoke the lookahead token's %destructor
170 https://lists.gnu.org/r/bug-bison/2018-02/msg00000.html
173 > Modifying yyclearin so that it calls yydestruct seems like the simplest
174 > solution to this issue, but it is conceivable that such a change would
175 > break programs which already perform some kind of workaround in order to
176 > destruct the lookahead symbol. So it might be necessary to use some kind of
177 > compatibility %define, or to create a new replacement macro with a
178 > different name such as yydiscardin.
180 > At a minimum, the fact that yyclearin does not invoke the %destructor
181 > should be highlighted in the documentation, since it is not at all obvious.
185 Les catégories d'avertissements incluent :
186 conflicts-sr conflits S/R (activé par défaut)
187 conflicts-rr conflits R/R (activé par défaut)
188 dangling-alias l'alias chaîne n'est pas attaché à un symbole
189 deprecated construction obsolète
190 empty-rule règle vide sans %empty
191 midrule-values valeurs de règle intermédiaire non définies ou inutilisées
192 precedence priorité et associativité inutiles
193 yacc incompatibilités avec POSIX Yacc
194 other tous les autres avertissements (activé par défaut)
195 all tous les avertissements sauf « dangling-alias » et « yacc »
196 no-CATEGORY désactiver les avertissements dans CATEGORIE
197 none désactiver tous les avertissements
198 error[=CATEGORY] traiter les avertissements comme des erreurs
200 Line -1 and -3 should mention CATEGORIE, not CATEGORY.
203 ** Rewrite glr.cc (currently glr2.cc)
205 We can probably replace setjmp/longjmp with exceptions. That would help
206 tremendously other languages such as D and Java that probably have no
207 similar feature. If we remove jumps, we probably no longer need _Noreturn,
208 so simplify `b4_attribute_define([noreturn])` into `b4_attribute_define`.
210 After discussing with Valentin, it was decided that it's better to stay with
211 jumps, since in some places exceptions are ruled out from C++.
214 Move to our coding conventions. In particular names such as yy_glr_stack,
218 It should be a member of the parser object, see lalr1.cc. Let the parser
219 object decide what the debug stream is, rather than open coding std::cerr.
222 There are many places where pointers should be replaced with references.
223 Some occurrences were fixed, but now some have improper names:
225 -yygetToken (int *yycharp, ]b4_namespace_ref[::]b4_parser_class[& yyparser][]b4_pure_if([, glr_stack* yystackp])[]b4_user_formals[)
226 +yygetToken (int& yycharp, ]b4_namespace_ref[::]b4_parser_class[& yyparser][]b4_pure_if([, glr_stack* yystackp])[]b4_user_formals[)
228 yycharp is no longer a Pointer. And yystackp should probably also be a reference.
231 Currently all the assertions are enabled. Once we are confident in glr2.cc,
232 let parse.assert use the same approach as in lalr1.cc.
235 Stop using std::cerr everywhere.
238 When glr2.cc fully replaces glr.cc, get rid of the glr.cc scaffolding in
242 ** Unit rules / Injection rules (Akim Demaille)
243 Maybe we could expand unit rules (or "injections", see
244 https://homepages.cwi.nl/~daybuild/daily-books/syntax/2-sdf/sdf.html), i.e.,
253 exp: exp '+' exp | exp '&' exp;
255 when there are no actions. This can significantly speed up some grammars.
256 I can't find the papers. In particular the book 'LR parsing: Theory and
257 Practice' is impossible to find, but according to 'Parsing Techniques: a
258 Practical Guide', it includes information about this issue. Does anybody
261 ** clean up (Akim Demaille)
262 Do not work on these items now, as I (Akim) have branches with a lot of
263 changes in this area (hitting several files), and no desire to have to fix
264 conflicts. Addressing these items will happen after my branches have been
268 Introduce a goto struct, and use it in place of from_state/to_state.
269 Rename states1 as path, length as pathlen.
270 Introduce inline functions for things such as nullable[*rp - ntokens]
271 where we need to map from symbol number to nterm number.
273 There are probably a significant part of the relations management that
274 should be migrated on top of a bitsetv.
277 It should probably take a "state*" instead of two arguments.
280 The "automaton" and "set" categories are not so useful. We should probably
281 introduce lr(0) and lalr, just the way we have ielr categories. The
282 "closure" function is too verbose, it should probably have its own category.
284 "set" can still be used for summarizing the important sets. That would make
285 tests easy to maintain.
288 Rename these guys as "diagnostics.*" (or "diagnose.*"), since that's the
289 name they have in GCC, clang, etc. Likewise for the complain_* series of
293 states/nstates, rules/nrules, ..., ritem/nritems
296 *** m4: slot, type, type_tag
297 The meaning of type_tag varies depending on api.value.type. We should avoid
298 that and using clear definitions with stable semantics.
300 * D programming language
301 There's a number of features that are missing, here sorted in _suggested_
302 order of implementation.
304 When copying code from other skeletons, keep the comments exactly as they
305 are. Keep the same variable names. If you change the wording in one place,
306 do it in the others too. In other words: make sure to keep the
307 maintenance *simple* by avoiding any gratuitous difference.
310 Check when gdc and ldc.
313 This is very ambitious. That's the final boss. There are currently no
314 "clean" implementation to get inspiration from.
316 glr.c is very clean but:
318 - is a different skeleton from yacc.c
320 glr.cc is (currently) an ugly hack: a C++ shell around glr.c. Valentin
321 Tolmer is currently rewriting glr.cc to be clean C++, but he is not
322 finished. There will be a lot a common code between lalr1.cc and glr.cc, so
323 eventually I would like them to be fused into a single skeleton, supporting
324 both deterministic and generalized parsing.
326 It would be great for D to also support this.
328 The basic ideas of GLR are explained here:
330 https://www.codeproject.com/Articles/5259825/GLR-Parsing-in-Csharp-How-to-Use-The-Most-Powerful
332 * Better error messages
333 The users are not provided with enough tools to forge their error messages.
334 See for instance "Is there an option to change the message produced by
335 YYERROR_VERBOSE?" by Simon Sobisch, on bison-help.
338 https://www.cs.tufts.edu/~nr/cs257/archive/clinton-jefferey/lr-error-messages.pdf
339 https://research.swtch.com/yyerror
340 http://gallium.inria.fr/~fpottier/publis/fpottier-reachability-cc2016.pdf
343 Fix data/skeletons/yacc.c so that it defines YYPTRDIFF_T properly for modern
344 and older C++ compilers. Currently the code defaults to defining it to
345 'long' for non-GCC compilers, but it should use the proper C++ magic to
346 define it to the same type as the C ptrdiff_t type.
349 Several features are not available in all the back-ends.
351 - push parsers: glr.c, glr.cc, lalr1.cc (not very difficult)
352 - token constructors: Java, C, D (a bit difficult)
353 - glr: D, Java (super difficult)
356 ** Autotest has quotation issues
357 tests/input.at:1730:AT_SETUP([%define errors])
361 $ ./tests/testsuite -l | grep errors | sed q
362 38: input.at:1730 errors
365 ** Better design for diagnostics
366 The current implementation of diagnostics is ad hoc, it grew organically.
367 It works as a series of calls to several functions, with dependency of the
368 latter calls on the former. For instance:
370 complain (&sym->location,
371 sym->content->status == needed ? complaint : Wother,
372 _("symbol %s is used, but is not defined as a token"
373 " and has no rules; did you mean %s?"),
374 quote_n (0, sym->tag),
375 quote_n (1, best->tag));
376 if (feature_flag & feature_caret)
377 location_caret_suggestion (sym->location, best->tag, stderr);
379 We should rewrite this in a more FP way:
381 1. build a rich structure that denotes the (complete) diagnostic.
382 "Complete" in the sense that it also contains the suggestions, the list
383 of possible matches, etc.
385 2. send this to the pretty-printing routine. The diagnostic structure
386 should be sufficient so that we can generate all the 'format' of
387 diagnostics, including the fixits.
389 If properly done, this diagnostic module can be detached from Bison and be
390 put in gnulib. It could be used, for instance, for errors caught by
393 There's certainly already something alike in GCC. At least that's the
394 impression I get from reading the "-fdiagnostics-format=FORMAT" part of this
397 https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html
399 ** Graphviz display code thoughts
400 The code for the --graph option is over two files: print_graph, and
401 graphviz. This is because Bison used to also produce VCG graphs, but since
402 this is no longer true, maybe we could consider these files for fusion.
404 An other consideration worth noting is that print_graph.c (correct me if I
405 am wrong) should contain generic functions, whereas graphviz.c and other
406 potential files should contain just the specific code for that output
407 format. It will probably prove difficult to tell if the implementation is
408 actually generic whilst only having support for a single format, but it
409 would be nice to keep stuff a bit tidier: right now, the construction of the
410 bitset used to show reductions is in the graphviz-specific code, and on the
411 opposite side we have some use of \l, which is graphviz-specific, in what
412 should be generic code.
414 Little effort seems to have been given to factoring these files and their
415 print{,-xml} counterpart. We would very much like to re-use the pretty format
416 of states from .output for the graphs, etc.
418 Since graphviz dies on medium-to-big grammars, maybe consider an other tool?
421 Check it too when checking the different kinds of parsers. And be
422 sure to check that the initial-action is performed once per parsing.
425 b4_shared_declarations is no longer what it is. Make it
426 b4_parser_declaration for instance.
428 ** yychar in lalr1.cc
429 There is a large difference bw maint and master on the handling of
430 yychar (which was removed in lalr1.cc). See what needs to be
434 /* User semantic actions sometimes alter yychar, and that requires
435 that yytoken be updated with the new translation. We take the
436 approach of translating immediately before every use of yytoken.
437 One alternative is translating here after every semantic action,
438 but that translation would be missed if the semantic action
439 invokes YYABORT, YYACCEPT, or YYERROR immediately after altering
440 yychar. In the case of YYABORT or YYACCEPT, an incorrect
441 destructor might then be invoked immediately. In the case of
442 YYERROR, subsequent parser actions might lead to an incorrect
443 destructor call or verbose syntax error message before the
444 lookahead is translated. */
446 /* Make sure we have latest lookahead translation. See comments at
447 user semantic actions for why this is necessary. */
448 yytoken = yytranslate_ (yychar);
451 ** Get rid of fake #lines [Bison: ...]
452 Possibly as simple as checking whether the column number is nonnegative.
454 I have seen messages like the following from GCC.
456 <built-in>:0: fatal error: opening dependency file .deps/libltdl/argz.Tpo: No such file or directory
459 ** Discuss about %printer/%destroy in the case of C++.
460 It would be very nice to provide the symbol classes with an operator<<
461 and a destructor. Unfortunately the syntax we have chosen for
462 %destroy and %printer make them hard to reuse. For instance, the user
463 is invited to write something like
465 %printer { debug_stream() << $$; } <my_type>;
467 which is hard to reuse elsewhere since it wants to use
468 "debug_stream()" to find the stream to use. The same applies to
469 %destroy: we told the user she could use the members of the Parser
470 class in the printers/destructors, which is not good for an operator<<
471 since it is no longer bound to a particular parser, it's just a
475 ** Rewrite glr.cc in C++ (Valentin Tolmer)
476 As a matter of fact, it would be very interesting to see how much we can
477 share between lalr1.cc and glr.cc. Most of the skeletons should be common.
478 It would be a very nice source of inspiration for the other languages.
480 Valentin Tolmer is working on this.
482 * From lalr1.cc to yacc.c
484 Merging the three stacks in lalr1.cc simplified the code, prompted for
485 other improvements and also made it faster (probably because memory
486 management is performed once instead of three times). I suggest that
487 we do the same in yacc.c.
489 (Some time later): it's also very nice to have three stacks: it's more dense
490 as we don't lose bits to padding. For instance the typical stack for states
491 will use 8 bits, while it is likely to consume 32 bits in a struct.
493 We need trustworthy benchmarks for Bison, for all our backends. Akim has a
494 few things scattered around; we need to put them in the repo, and make them
500 Some statistics about the grammar and the parser would be useful,
501 especially when asking the user to send some information about the
502 grammars she is working on. We should probably also include some
503 information about the variables (I'm not sure for instance we even
504 specify what LR variant was used).
507 How would Paul like to display the conflicted actions? In particular,
508 what when two reductions are possible on a given lookahead token, but one is
509 part of $default. Should we make the two reductions explicit, or just
510 keep $default? See the following point.
512 ** Disabled Reductions
513 See 'tests/conflicts.at (Defaulted Conflicted Reduction)', and decide
517 Extend with error productions. The hard part will probably be finding
518 the right rule so that a single state does not exhibit too many yet
519 undocumented ''features''. Maybe an empty action ought to be
520 presented too. Shall we try to make a single grammar with all these
521 features, or should we have several very small grammars?
525 Well, only if there is really some demand for it.
528 https://github.com/scfc/bison-php/blob/master/data/lalr1.php
531 https://lists.gnu.org/r/bison-patches/2013-09/msg00000.html and following
533 ** Multiple start symbols
534 Would be very useful when parsing closely related languages. The idea is to
535 declare several start symbols, for instance
542 and to generate parse(), parse_stmt() and parse_expr(). Technically, the
543 above grammar would be transformed into
546 %token YY_START_STMT YY_START_EXPR
548 yy_start: YY_START_STMT stmt | YY_START_EXPR expr
550 so that there are no new conflicts in the grammar (as would undoubtedly
551 happen with yy_start: stmt | expr). Then adjust the skeletons so that this
552 initial token (YY_START_STMT, YY_START_EXPR) be shifted first in the
553 corresponding parse function.
555 *** Number of useless symbols
559 [[input.y: warning: 2 nonterminals useless in grammar [-Wother]
560 input.y: warning: 2 rules useless in grammar [-Wother]
561 input.y:2.8-10: error: start symbol exp does not derive any sentence]])
563 We should say "1 nonterminal": the other one is $accept, which should not
564 participate in the count.
567 Do we want to disallow terminal start symbols? The limitation is not
568 technical. Can it be useful to someone to "parse" a token?
571 This is a popular demand. We already made many changes in the parser that
572 should make this reasonably easy to implement.
574 Bruce Mardle <marblypup@yahoo.co.uk>
575 https://lists.gnu.org/r/bison-patches/2015-09/msg00000.html
577 However, there are many other things to do before having such a feature,
578 because I don't want a % equivalent to #include (which we all learned to
579 hate). I want something that builds "modules" of grammars, and assembles
580 them together, paying attention to keep separate bits separated, in pseudo
584 There is demand for push parsers in C++.
586 ** Generate code instead of tables
587 This is certainly quite a lot of work. See
588 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.4539.
591 We should find a means to provide an access to values deep in the
592 stack. For instance, instead of
594 baz: qux { $$ = $<foo>-1 + $<bar>0 + $1; }
596 we should be able to have:
598 foo($foo) bar($bar) baz($bar): qux($qux) { $baz = $foo + $bar + $qux; }
600 Or something like this.
603 It should be possible to have %if/%else/%endif. The implementation is
604 not clear: should it be lexical or syntactic. Vadim Maslow thinks it
605 must be in the scanner: we must not parse what is in a switched off
606 part of %if. Akim Demaille thinks it should be in the parser, so as
607 to avoid falling into another CPP mistake.
609 (Later): I'm sure there's actually good case for this. People who need that
610 feature can use m4/cpp on top of Bison. I don't think it is worth the
611 trouble in Bison itself.
614 There are couple of available extensions of Bison targeting some XML
615 output. Some day we should consider including them. One issue is
616 that they seem to be quite orthogonal to the parsing technique, and
617 seem to depend mostly on the possibility to have some code triggered
618 for each reduction. As a matter of fact, such hooks could also be
619 used to generate the yydebug traces. Some generic scheme probably
622 XML output for GNU Bison and gcc
623 http://www.cs.may.ie/~jpower/Research/bisonXML/
625 XML output for GNU Bison
626 http://yaxx.sourceforge.net/
628 * Coding system independence
631 Currently Bison assumes 8-bit bytes (i.e. that UCHAR_MAX is
632 255). It also assumes that the 8-bit character encoding is
633 the same for the invocation of 'bison' as it is for the
634 invocation of 'cc', but this is not necessarily true when
635 people run bison on an ASCII host and then use cc on an EBCDIC
636 host. I don't think these topics are worth our time
637 addressing (unless we find a gung-ho volunteer for EBCDIC or
638 PDP-10 ports :-) but they should probably be documented
641 More importantly, Bison does not currently allow NUL bytes in
642 tokens, either via escapes (e.g., "x\0y") or via a NUL byte in
643 the source code. This should get fixed.
648 Must we keep %token-table?
653 It is unfortunate that there is a total order for precedence. It
654 makes it impossible to have modular precedence information. We should
655 move to partial orders (sounds like series/parallel orders to me).
657 This is a prerequisite for modules.
659 * Pre and post actions.
660 From: Florian Krohm <florian@edamail.fishkill.ibm.com>
661 Subject: YYACT_EPILOGUE
662 To: bug-bison@gnu.org
663 X-Sent: 1 week, 4 days, 14 hours, 38 minutes, 11 seconds ago
665 The other day I had the need for explicitly building the parse tree. I
666 used %locations for that and defined YYLLOC_DEFAULT to call a function
667 that returns the tree node for the production. Easy. But I also needed
668 to assign the S-attribute to the tree node. That cannot be done in
669 YYLLOC_DEFAULT, because it is invoked before the action is executed.
670 The way I solved this was to define a macro YYACT_EPILOGUE that would
671 be invoked after the action. For reasons of symmetry I also added
672 YYACT_PROLOGUE. Although I had no use for that I can envision how it
673 might come in handy for debugging purposes.
674 All is needed is to add
677 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen, yyloc, (yylsp - yylen));
679 YYACT_EPILOGUE (yyval, (yyvsp - yylen), yylen);
682 at the proper place to bison.simple. Ditto for YYACT_PROLOGUE.
684 I was wondering what you think about adding YYACT_PROLOGUE/EPILOGUE
685 to bison. If you're interested, I'll work on a patch.
688 Equip the parser with a means to create the (visual) parse tree.
693 # LocalWords: Cex gnulib gl Bistromathic TokenKinds yylex enum YYEOF EOF
694 # LocalWords: YYerror gettext af hb YYERRCODE undef calc FIXME dev yyerror
695 # LocalWords: Autoconf YYUNDEFTOK lexemes parsers Bistromathic's yyreport
696 # LocalWords: const argc yacc yyclearin lookahead destructor Rici incluent
697 # LocalWords: yydestruct yydiscardin catégories d'avertissements sr activé
698 # LocalWords: conflits défaut rr l'alias chaîne n'est attaché un symbole
699 # LocalWords: obsolète règle vide midrule valeurs de intermédiaire ou avec
700 # LocalWords: définies inutilisées priorité associativité inutiles POSIX
701 # LocalWords: incompatibilités tous les autres avertissements sauf dans rp
702 # LocalWords: désactiver CATEGORIE traiter comme des erreurs glr Akim bool
703 # LocalWords: Demaille arith lalr goto struct pathlen nullable ntokens lr
704 # LocalWords: nterm bitsetv ielr ritem nstates nrules nritems yysymbol EQ
705 # LocalWords: SymbolKind YYEMPTY YYUNDEF YYTNAME NUM yyntokens yytname sed
706 # LocalWords: nonterminals yykind yycode YYNAMES yynames init getName conv
707 # LocalWords: TokenKind ival yychar yylval yylexer Tolmer hoc
708 # LocalWords: Sobisch YYPTRDIFF ptrdiff Autotest toknum yytoknum
709 # LocalWords: sym Wother stderr FP fixits xgettext fdiagnostics Graphviz
710 # LocalWords: graphviz VCG bitset xml bw maint yytoken YYABORT deps
711 # LocalWords: YYACCEPT yytranslate nonnegative destructors yyerrlab repo
712 # LocalWords: backends stmt expr yy Mardle baz qux Vadim Maslow CPP cpp
713 # LocalWords: yydebug gcc UCHAR EBCDIC gung PDP NUL Pre Florian Krohm utf
714 # LocalWords: YYACT YYLLOC YYLSP yyval yyvsp yylen yyloc yylsp endif
715 # LocalWords: ispell american
721 ispell-dictionary: "american"
724 Copyright (C) 2001-2004, 2006, 2008-2015, 2018-2021 Free Software
727 This file is part of Bison, the GNU Compiler Compiler.
729 Permission is granted to copy, distribute and/or modify this document
730 under the terms of the GNU Free Documentation License, Version 1.3 or
731 any later version published by the Free Software Foundation; with no
732 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
733 Texts. A copy of the license is included in the "GNU Free
734 Documentation License" file as part of this distribution.