On Sun, 15 Oct 2006, Joel E. Denny wrote: > Section "3.1.1 The prologue" of the Bison manual has grown a new paragraph > since I last looked: > > When in doubt, it is usually safer to put prologue code before all > Bison declarations, rather than after. For example, any definitions of > feature test macros like `_GNU_SOURCE' or `_POSIX_C_SOURCE' should > appear before all Bison declarations, as feature test macros can affect > the behavior of Bison-generated `#include' directives. > > It invalidates the discussion of %code and %requires in the rest of that > section. This suggests we should have kept %before-header or some > equivalent.
I commited the following. If the Java skeletons aren't ready by the next release, we can remove the statements about Java then. I realize the NEWS entry is long, but I feel it's helpful to have that information up front. I'm quite open to feedback on it or any of the other changes. The new manual section could probably use better indexing and cross-referencing. Later perhaps. Index: ChangeLog =================================================================== RCS file: /sources/bison/bison/ChangeLog,v retrieving revision 1.1589 diff -p -u -r1.1589 ChangeLog --- ChangeLog 15 Oct 2006 22:37:54 -0000 1.1589 +++ ChangeLog 16 Oct 2006 05:11:34 -0000 @@ -1,3 +1,23 @@ +2006-10-16 Joel E. Denny <[EMAIL PROTECTED]> + + Similar to the recently removed %before-header, add %code-top as the + alternative to the pre-prologue. Mentioned at + <http://lists.gnu.org/archive/html/bison-patches/2006-10/msg00063.html>. + Also, let the prologue alternatives appear in the grammar section. + * src/parse-gram.y (PERCENT_CODE_TOP): New token. + (prologue_declaration): Move the existing prologue alternatives to... + (grammar_declaration): ... here and add %code-top. + * src/scan-gram.l (PERCENT_CODE_TOP): New token. + + Clean up and extend documentation for the prologue alternatives. + * NEWS (2.3a+): Describe prologue alternatives. + * doc/bison.texinfo (Prologue): Move discussion of prologue + alternatives to... + (Prologue Alternatives): ... this new section, and extend it to discuss + all 4 directives in detail. + (Bison Symbols): Clean up discussion of prologue alternatives and add + %code-top. + 2006-10-16 Juan Manuel Guerrero <[EMAIL PROTECTED]> DJGPP specific issues. Index: NEWS =================================================================== RCS file: /sources/bison/bison/NEWS,v retrieving revision 1.161 diff -p -u -r1.161 NEWS --- NEWS 12 Oct 2006 23:29:52 -0000 1.161 +++ NEWS 16 Oct 2006 05:11:34 -0000 @@ -6,6 +6,74 @@ Changes in version 2.3a+ (????-??-??): * The -g and --graph options now output graphs in Graphviz DOT format, not VCG format. +* The Yacc prologue alternatives from Bison 2.3a have been rewritten as the + following directives: + + 1. %code {CODE} + + Other than semantic actions, this is probably the most common place you + should write verbatim code for the parser implementation. For C/C++, it + replaces the traditional Yacc prologue, `%{CODE%}', for most purposes. + For Java, it inserts your CODE into the parser class. Compare with: + + - `%{CODE%}' appearing after the first `%union {CODE}' in a C/C++ + based grammar file. While Bison will continue to support `%{CODE%}' + for backward compatibility, `%code {CODE}' is cleaner as its + functionality does not depend on its position in the grammar file + relative to any `%union {CODE}'. Specifically, `%code {CODE}' + always inserts your CODE into the parser code file after the usual + contents of the parser header file. + - `%after-header {CODE}', which only Bison 2.3a supported. + + 2. %requires {CODE} + + This is the right place to write dependency code for externally exposed + definitions required by Bison. For C/C++, such exposed definitions are + those usually appearing in the parser header file. Thus, this is the + right place to define types referenced in `%union {CODE}' directives, + and it is the right place to override Bison's default YYSTYPE and + YYLTYPE definitions. For Java, this is the right place to write import + directives. Compare with: + + - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++ + based grammar file. Unlike `%{CODE%}', `%requires {CODE}' inserts + your CODE both into the parser code file and into the parser header + file since Bison's required definitions should depend on it in both + places. + - `%start-header {CODE}', which only Bison 2.3a supported. + + 3. %provides {CODE} + + This is the right place to write additional definitions you would like + Bison to expose externally. For C/C++, this directive inserts your CODE + both into the parser header file and into the parser code file after + Bison's required definitions. For Java, it inserts your CODE into the + parser java file after the parser class. Compare with: + + - `%end-header {CODE}', which only Bison 2.3a supported. + + 4. %code-top {CODE} + + Occasionally for C/C++ it is desirable to insert code near the top of + the parser code file. For example: + + %code-top { + #define _GNU_SOURCE + #include <stdio.h> + } + + For Java, `%code-top {CODE}' is currently unused. Compare with: + + - `%{CODE%}' appearing before the first `%union {CODE}' in a C/C++ + based grammar file. `%code-top {CODE}' is cleaner as its + functionality does not depend on its position in the grammar file + relative to any `%union {CODE}'. + - `%before-header {CODE}', which only Bison 2.3a supported. + + If you have multiple occurrences of any one of the above four directives, + Bison will concatenate the contents in the order they appear in the grammar + file. + Changes in version 2.3a, 2006-09-13: * Instead of %union, you can define and use your own union type Index: doc/bison.texinfo =================================================================== RCS file: /sources/bison/bison/doc/bison.texinfo,v retrieving revision 1.207 diff -p -u -r1.207 bison.texinfo --- doc/bison.texinfo 15 Oct 2006 12:37:07 -0000 1.207 +++ doc/bison.texinfo 16 Oct 2006 05:11:38 -0000 @@ -191,6 +191,7 @@ Bison Grammar Files Outline of a Bison Grammar * Prologue:: Syntax and usage of the prologue. +* Prologue Alternatives:: Syntax and usage of alternatives to the prologue. * Bison Declarations:: Syntax and usage of the Bison declarations section. * Grammar Rules:: Syntax and usage of the grammar rules section. * Epilogue:: Syntax and usage of the epilogue. @@ -2616,6 +2617,7 @@ continues until end of line. @menu * Prologue:: Syntax and usage of the prologue. +* Prologue Alternatives:: Syntax and usage of alternatives to the prologue. * Bison Declarations:: Syntax and usage of the Bison declarations section. * Grammar Rules:: Syntax and usage of the grammar rules section. * Epilogue:: Syntax and usage of the epilogue. @@ -2674,16 +2676,128 @@ of feature test macros like @code{_GNU_S feature test macros can affect the behavior of Bison-generated @code{#include} directives. [EMAIL PROTECTED] %requires [EMAIL PROTECTED] Prologue Alternatives [EMAIL PROTECTED] Prologue Alternatives [EMAIL PROTECTED] Prologue Alternatives + @findex %code -If you've instructed Bison to generate a header file (@pxref{Table of Symbols, -,%defines}), you probably want @code{#include "ptypes.h"} to appear -in that header file as well. -In that case, use @code{%requires}, @code{%provides}, and [EMAIL PROTECTED] instead of @var{Prologue} sections -(@pxref{Table of Symbols, ,%requires}): [EMAIL PROTECTED] %requires [EMAIL PROTECTED] %provides [EMAIL PROTECTED] %code-top +The functionality of @var{Prologue} sections can often be subtle and +inflexible. +As an alternative, Bison provides a set of more explicit directives: [EMAIL PROTECTED], @code{%requires}, @code{%provides}, and @code{%code}. [EMAIL PROTECTED] of Symbols}. + +Look again at the example of the previous section: @smallexample [EMAIL PROTECTED] + #define _GNU_SOURCE + #include <stdio.h> + #include "ptypes.h" [EMAIL PROTECTED] + +%union @{ + long int n; + tree t; /* @[EMAIL PROTECTED] is defined in @file{ptypes.h}.} */ [EMAIL PROTECTED] + [EMAIL PROTECTED] + static void print_token_value (FILE *, int, YYSTYPE); + #define YYPRINT(F, N, L) print_token_value (F, N, L) [EMAIL PROTECTED] + [EMAIL PROTECTED] [EMAIL PROTECTED] smallexample + [EMAIL PROTECTED] +Notice that there are two @var{Prologue} sections here, but there's a subtle +distinction between their functionality. +For example, if you decide to override Bison's default definition for [EMAIL PROTECTED], in which @var{Prologue} section should you write your new +definition? +You should write it in the first since Bison will insert that code into the +parser code file @emph{before} the default @code{YYLTYPE} definition. +In which @var{Prologue} section should you prototype an internal function, [EMAIL PROTECTED], that accepts @code{YYLTYPE} and @code{yytokentype} as +arguments? +You should prototype it in the second since Bison will insert that code [EMAIL PROTECTED] the @code{YYLTYPE} and @code{yytokentype} definitions. + +This distinction in functionality between the two @var{Prologue} sections is +established by the appearance of the @code{%union} between them. +This behavior raises several questions. +First, why should the position of a @code{%union} affect definitions related to [EMAIL PROTECTED] and @code{yytokentype}? +Second, what if there is no @code{%union}? +In that case, the second kind of @var{Prologue} section is not available. +This behavior is not intuitive. + +To avoid this subtle @code{%union} dependency, rewrite the example using [EMAIL PROTECTED] and @code{%code}. +Let's go ahead and add the new @code{YYLTYPE} definition and the [EMAIL PROTECTED] prototype at the same time: + [EMAIL PROTECTED] +%code-top @{ + #define _GNU_SOURCE + #include <stdio.h> + /* The following code really belongs in a %requires; see below. */ + #include "ptypes.h" + #define YYLTYPE YYLTYPE + typedef struct YYLTYPE + @{ + int first_line; + int first_column; + int last_line; + int last_column; + char *filename; + @} YYLTYPE; [EMAIL PROTECTED] + +%union @{ + long int n; + tree t; /* @[EMAIL PROTECTED] is defined in @file{ptypes.h}.} */ [EMAIL PROTECTED] + +%code @{ + static void print_token_value (FILE *, int, YYSTYPE); + #define YYPRINT(F, N, L) print_token_value (F, N, L) + static void trace_token (enum yytokentype token, YYLTYPE loc); [EMAIL PROTECTED] + [EMAIL PROTECTED] [EMAIL PROTECTED] smallexample + [EMAIL PROTECTED] +In this way, @code{%code-top} and @code{%code} achieve the same functionality +as the two kinds of @var{Prologue} sections, but it's always explicit which +kind you intend. +Moreover, both kinds are always available even in the absence of @code{%union}. + +The first @var{Prologue} section above now logically contains two parts. +The first two lines need to appear in the parser code file. +The fourth line is required by @code{YYSTYPE} and thus also needs to appear in +the parser code file. +However, if you've instructed Bison to generate a parser header file +(@pxref{Table of Symbols, ,%defines}), you probably want the third line to +appear before the @code{YYSTYPE} definition in that header file as well. +Also, the @code{YYLTYPE} definition should appear in the parser header file to +override the default @code{YYLTYPE} definition there. + +In other words, in the first @var{Prologue} section, all but the first two +lines are dependency code for externally exposed definitions (@code{YYSTYPE} +and @code{YYLTYPE}) required by Bison. +Thus, they belong in one or more @code{%requires}: + [EMAIL PROTECTED] +%code-top @{ + #define _GNU_SOURCE + #include <stdio.h> [EMAIL PROTECTED] + %requires @{ #include "ptypes.h" @} @@ -2692,9 +2806,76 @@ In that case, use @code{%requires}, @cod tree t; /* @[EMAIL PROTECTED] is defined in @file{ptypes.h}.} */ @} +%requires @{ + #define YYLTYPE YYLTYPE + typedef struct YYLTYPE + @{ + int first_line; + int first_column; + int last_line; + int last_column; + char *filename; + @} YYLTYPE; [EMAIL PROTECTED] + %code @{ + static void print_token_value (FILE *, int, YYSTYPE); + #define YYPRINT(F, N, L) print_token_value (F, N, L) + static void trace_token (enum yytokentype token, YYLTYPE loc); [EMAIL PROTECTED] + [EMAIL PROTECTED] [EMAIL PROTECTED] smallexample + [EMAIL PROTECTED] +Now Bison will insert @code{#include "ptypes.h"} and the new @code{YYLTYPE} +definition before the Bison-generated @code{YYSTYPE} and @code{YYLTYPE} +definitions in both the parser code file and the parser header file. +(By the same reasoning, @code{%requires} would also be the appropriate place to +write your own definition for @code{YYSTYPE}.) + +At some point while developing your parser, you might decide to provide [EMAIL PROTECTED] to modules that are external to your parser. +Thus, you might wish for Bison to insert the prototype into both the parser +header file and the parser code file. +Since this function is not a dependency of any Bison-required definition (such +as @code{YYSTYPE}), it doesn't make sense to move its prototype to a [EMAIL PROTECTED] +More importantly, since it depends upon @code{YYLTYPE} and @code{yytokentype}, [EMAIL PROTECTED] is not sufficient. +Instead, move its prototype from the @code{%code} to a @code{%provides}: + [EMAIL PROTECTED] +%code-top @{ + #define _GNU_SOURCE #include <stdio.h> [EMAIL PROTECTED] +%requires @{ + #include "ptypes.h" [EMAIL PROTECTED] +%union @{ + long int n; + tree t; /* @[EMAIL PROTECTED] is defined in @file{ptypes.h}.} */ [EMAIL PROTECTED] + +%requires @{ + #define YYLTYPE YYLTYPE + typedef struct YYLTYPE + @{ + int first_line; + int first_column; + int last_line; + int last_column; + char *filename; + @} YYLTYPE; [EMAIL PROTECTED] + +%provides @{ + void trace_token (enum yytokentype token, YYLTYPE loc); [EMAIL PROTECTED] + +%code @{ static void print_token_value (FILE *, int, YYSTYPE); #define YYPRINT(F, N, L) print_token_value (F, N, L) @} @@ -2702,6 +2883,49 @@ In that case, use @code{%requires}, @cod @dots{} @end smallexample [EMAIL PROTECTED] +Bison will insert the @code{trace_token} prototype into both the parser header +file and the parser code file after the definitions for @code{yytokentype}, [EMAIL PROTECTED], and @code{YYSTYPE}. + +The above examples are careful to write directives in an order that reflects +the layout of the generated parser code and header files: [EMAIL PROTECTED], @code{%requires}, @code{%provides}, and then @code{%code}. +While your grammar files will generally be easier to read if you also follow +this order, Bison does not require it. +Instead, Bison lets you choose an organization that makes sense to you. + +Any of these directives may be declared multiple times in the grammar file. +In that case, Bison concatenates the contained code in declaration order. +This is the only way in which the position of one of these directives within +the grammar file affects its functionality. + +The result of the previous two properties is greater flexibility in how you may +organize your grammar file. +For example, you may organize semantic-type-related directives by semantic +type: + [EMAIL PROTECTED] +%requires @{ #include "type1.h" @} +%union @{ type1 field1; @} +%destructor @{ type1_free ($$); @} <field1> +%printer @{ type1_print ($$); @} <field1> + +%requires @{ #include "type2.h" @} +%union @{ type2 field2; @} +%destructor @{ type2_free ($$); @} <field2> +%printer @{ type2_print ($$); @} <field2> [EMAIL PROTECTED] smallexample + [EMAIL PROTECTED] +You could even place each of the above directive groups in the rules section of +the grammar file next to the set of rules that uses the associated semantic +type. +And you don't have to worry that some directive (like a @code{%union}) in the +definitions section is going to adversely affect their functionality in some +counter-intuitive manner just because it comes first. +Such an organization is not possible using @var{Prologue} sections. + @node Bison Declarations @subsection The Bison Declarations Section @cindex Bison declarations (introduction) @@ -8306,65 +8530,51 @@ Start-Symbol}. It cannot be used in the @end deffn @deffn {Directive} %code @[EMAIL PROTECTED]@} -Specifies code to be inserted into the code file after the contents of the -header file. [EMAIL PROTECTED] of Symbols, ,%requires}. [EMAIL PROTECTED] deffn - [EMAIL PROTECTED] {Directive} %provides @[EMAIL PROTECTED]@} -Specifies code to be inserted both into the header file (if generated; [EMAIL PROTECTED] of Symbols, ,%defines}) and into the code file after any -Bison-generated definitions. [EMAIL PROTECTED] of Symbols, ,%requires}. [EMAIL PROTECTED] deffn - [EMAIL PROTECTED] {Directive} %requires @[EMAIL PROTECTED]@} -Specifies code to be inserted both into the header file (if generated; [EMAIL PROTECTED] of Symbols, ,%defines}) and into the code file before any -Bison-generated definitions. +Other than semantic actions, this is probably the most common place you should +write verbatim code for the parser implementation. +For C/C++, it replaces the traditional Yacc prologue, [EMAIL PROTECTED]@[EMAIL PROTECTED]@}}, for most purposes. +For Java, it inserts code into the parser class. @cindex Prologue @findex %union [EMAIL PROTECTED] %provides [EMAIL PROTECTED] %code -For example, the following declaration order in the grammar file reflects the -order in which Bison will output these code blocks. However, you are free to -declare these code blocks in your grammar file in whatever order is most -convenient for you: +Compare with @[EMAIL PROTECTED]@[EMAIL PROTECTED] (@pxref{Prologue, ,The Prologue}) +appearing after the first @code{%union @[EMAIL PROTECTED]@}} in a C/C++ based grammar +file. +While Bison will continue to support @[EMAIL PROTECTED]@[EMAIL PROTECTED] for backward +compatibility, @code{%code @[EMAIL PROTECTED]@}} is cleaner as its functionality does +not depend on its position in the grammar file relative to any [EMAIL PROTECTED] @[EMAIL PROTECTED]@}}. +Specifically, @code{%code @[EMAIL PROTECTED]@}} always inserts your @var{code} into +the parser code file after the usual contents of the parser header file. + [EMAIL PROTECTED] Alternatives}. [EMAIL PROTECTED] deffn + [EMAIL PROTECTED] {Directive} %code-top @[EMAIL PROTECTED]@} +Occasionally for C/C++ it is desirable to insert code near the top of the +parser code file. +For example: @smallexample -%requires @{ - /* Bison inserts this block into both the header file and the code - * file. In both files, the point of insertion is before any - * Bison-generated token, semantic type, location type, and class - * definitions. This is a good place to define %union - * dependencies, for example. */ [EMAIL PROTECTED] -%union @{ - /* Unlike the traditional Yacc prologue blocks, the output order - * for %requires, %provides or %code blocks is not affected by their - * declaration position relative to any %union in the grammar file. */ [EMAIL PROTECTED] -%provides @{ - /* Bison inserts this block into both the header file and the code - * file. In both files, the point of insertion is after the - * Bison-generated definitions. This is a good place to declare or - * define public functions or data structures that depend on the - * Bison-generated definitions. */ [EMAIL PROTECTED] -%code @{ - /* Bison treats this block like a post-prologue block: it inserts - * it into the code file after the contents of the header file. It - * does *not* insert it into the header file. This is a good place - * to declare or define internal functions or data structures that - * depend on the Bison-generated definitions. */ +%code-top @{ + #define _GNU_SOURCE + #include <stdio.h> @} @end smallexample -If you have multiple occurrences of any one of the above declarations, Bison -will concatenate the contents in declaration order. [EMAIL PROTECTED] +For Java, @code{%code-top @[EMAIL PROTECTED]@}} is currently unused. + [EMAIL PROTECTED] Prologue [EMAIL PROTECTED] %union +Compare with @[EMAIL PROTECTED]@[EMAIL PROTECTED] appearing before the first [EMAIL PROTECTED] @[EMAIL PROTECTED]@}} in a C/C++ based grammar file. [EMAIL PROTECTED] @[EMAIL PROTECTED]@}} is cleaner as its functionality does not depend +on its position in the grammar file relative to any [EMAIL PROTECTED] @[EMAIL PROTECTED]@}}. [EMAIL PROTECTED], ,The Prologue}. [EMAIL PROTECTED] Alternatives}. @end deffn @deffn {Directive} %debug @@ -8490,6 +8700,18 @@ Bison declaration to assign a precedence @xref{Contextual Precedence, ,Context-Dependent Precedence}. @end deffn [EMAIL PROTECTED] {Directive} %provides @[EMAIL PROTECTED]@} +This is the right place to write additional definitions you would like Bison to +expose externally. +For C/C++, this directive inserts your @var{code} both into the parser header +file (if generated; @pxref{Table of Symbols, ,%defines}) and into the parser +code file after Bison's required definitions. +For Java, it inserts your @var{code} into the parser java file after the parser +class. + [EMAIL PROTECTED] Alternatives}. [EMAIL PROTECTED] deffn + @deffn {Directive} %pure-parser Bison declaration to request a pure (reentrant) parser. @xref{Pure Decl, ,A Pure (Reentrant) Parser}. @@ -8500,6 +8722,29 @@ Require version @var{version} or higher Require a Version of Bison}. @end deffn [EMAIL PROTECTED] {Directive} %requires @[EMAIL PROTECTED]@} +This is the right place to write dependency code for externally exposed +definitions required by Bison. +For C/C++, such exposed definitions are those usually appearing in the parser +header file. +Thus, this is the right place to define types referenced in [EMAIL PROTECTED] @[EMAIL PROTECTED]@}} directives, and it is the right place to override +Bison's default @code{YYSTYPE} and @code{YYLTYPE} definitions. +For Java, this is the right place to write import directives. + [EMAIL PROTECTED] Prologue [EMAIL PROTECTED] %union +Compare with @[EMAIL PROTECTED]@[EMAIL PROTECTED] (@pxref{Prologue, ,The Prologue}) +appearing before the first @code{%union @[EMAIL PROTECTED]@}} in a C/C++ based +grammar file. +Unlike @[EMAIL PROTECTED]@[EMAIL PROTECTED], @code{%requires @[EMAIL PROTECTED]@}} inserts your [EMAIL PROTECTED] both into the parser code file and into the parser header file (if +generated; @pxref{Table of Symbols, ,%defines}) since Bison's required +definitions should depend on it in both places. + [EMAIL PROTECTED] Alternatives}. [EMAIL PROTECTED] deffn + @deffn {Directive} %right Bison declaration to assign right associativity to token(s). @xref{Precedence Decl, ,Operator Precedence}. Index: src/parse-gram.y =================================================================== RCS file: /sources/bison/bison/src/parse-gram.y,v retrieving revision 1.93 diff -p -u -r1.93 parse-gram.y --- src/parse-gram.y 15 Oct 2006 12:37:07 -0000 1.93 +++ src/parse-gram.y 16 Oct 2006 05:11:38 -0000 @@ -134,6 +134,7 @@ static int current_prec = 0; %token PERCENT_CODE "%code" + PERCENT_CODE_TOP "%code-top" PERCENT_DEBUG "%debug" PERCENT_DEFAULT_PREC "%default-prec" PERCENT_DEFINE "%define" @@ -221,7 +222,6 @@ prologue_declarations: prologue_declaration: grammar_declaration | "%{...%}" { prologue_augment (translate_code ($1, @1), @1, union_seen); } -| "%code" braceless { prologue_augment ($2, @2, true); } | "%debug" { debug_flag = true; } | "%define" STRING content.opt { muscle_insert ($2, $3); } | "%defines" { defines_flag = true; } @@ -245,11 +245,9 @@ prologue_declaration: | "%nondeterministic-parser" { nondeterministic_parser = true; } | "%output" "=" STRING { spec_outfile = $3; } | "%parse-param" "{...}" { add_param ("parse_param", $2, @2); } -| "%provides" braceless { muscle_code_grow ("provides", $2, @2); } | "%pure-parser" { pure_parser = true; } | "%push-parser" { push_parser = true; } | "%require" STRING { version_check (&@2, $2); } -| "%requires" braceless { muscle_code_grow ("requires", $2, @2); } | "%skeleton" STRING { skeleton = $2; } | "%token-table" { token_table_flag = true; } | "%verbose" { report_flag = report_states; } @@ -288,6 +286,10 @@ grammar_declaration: { default_prec = false; } +| "%code" braceless { prologue_augment ($2, @2, true); } +| "%code-top" braceless { prologue_augment ($2, @2, false); } +| "%provides" braceless { muscle_code_grow ("provides", $2, @2); } +| "%requires" braceless { muscle_code_grow ("requires", $2, @2); } ; Index: src/reader.c =================================================================== RCS file: /sources/bison/bison/src/reader.c,v retrieving revision 1.272 diff -p -u -r1.272 reader.c --- src/reader.c 15 Sep 2006 16:34:48 -0000 1.272 +++ src/reader.c 16 Oct 2006 05:11:39 -0000 @@ -72,7 +72,7 @@ grammar_start_symbol_set (symbol *sym, l /*---------------------------------------------------------------------. | There are two prologues: one before the first %union and one after. | -| Augment the one specified by POST. | +| Augment the one specified by POST. | `---------------------------------------------------------------------*/ void Index: src/scan-gram.l =================================================================== RCS file: /sources/bison/bison/src/scan-gram.l,v retrieving revision 1.104 diff -p -u -r1.104 scan-gram.l --- src/scan-gram.l 15 Oct 2006 12:37:07 -0000 1.104 +++ src/scan-gram.l 16 Oct 2006 05:11:39 -0000 @@ -158,6 +158,7 @@ splice (\\[ \f\t\v]*\n)* { "%binary" return PERCENT_NONASSOC; "%code" return PERCENT_CODE; + "%code-top" return PERCENT_CODE_TOP; "%debug" return PERCENT_DEBUG; "%default"[-_]"prec" return PERCENT_DEFAULT_PREC; "%define" return PERCENT_DEFINE;
