Re: feature tests and %before-header

[Joel E. Denny]

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  <address@hidden>
+
+       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  <address@hidden>
 
        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.
 
address@hidden %requires
address@hidden Prologue Alternatives
address@hidden Prologue Alternatives
address@hidden 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
address@hidden instead of @var{Prologue} sections
-(@pxref{Table of Symbols, ,%requires}):
address@hidden %requires
address@hidden %provides
address@hidden %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:
address@hidden, @code{%requires}, @code{%provides}, and @code{%code}.
address@hidden of Symbols}.
+
+Look again at the example of the previous section:
 
 @smallexample
address@hidden
+  #define _GNU_SOURCE
+  #include <stdio.h>
+  #include "ptypes.h"
address@hidden
+
+%union @{
+  long int n;
+  tree t;  /* @address@hidden is defined in @file{ptypes.h}.} */
address@hidden
+
address@hidden
+  static void print_token_value (FILE *, int, YYSTYPE);
+  #define YYPRINT(F, N, L) print_token_value (F, N, L)
address@hidden
+
address@hidden
address@hidden smallexample
+
address@hidden
+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
address@hidden, 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,
address@hidden, that accepts @code{YYLTYPE} and @code{yytokentype} as
+arguments?
+You should prototype it in the second since Bison will insert that code
address@hidden 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
address@hidden 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
address@hidden and @code{%code}.
+Let's go ahead and add the new @code{YYLTYPE} definition and the
address@hidden prototype at the same time:
+
address@hidden
+%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;
address@hidden
+
+%union @{
+  long int n;
+  tree t;  /* @address@hidden is defined in @file{ptypes.h}.} */
address@hidden
+
+%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);
address@hidden
+
address@hidden
address@hidden smallexample
+
address@hidden
+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}:
+
address@hidden
+%code-top @{
+  #define _GNU_SOURCE
+  #include <stdio.h>
address@hidden
+
 %requires @{
   #include "ptypes.h"
 @}
@@ -2692,9 +2806,76 @@ In that case, use @code{%requires}, @cod
   tree t;  /* @address@hidden 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;
address@hidden
+
 %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);
address@hidden
+
address@hidden
address@hidden smallexample
+
address@hidden
+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
address@hidden 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
address@hidden
+More importantly, since it depends upon @code{YYLTYPE} and @code{yytokentype},
address@hidden is not sufficient.
+Instead, move its prototype from the @code{%code} to a @code{%provides}:
+
address@hidden
+%code-top @{
+  #define _GNU_SOURCE
   #include <stdio.h>
address@hidden
 
+%requires @{
+  #include "ptypes.h"
address@hidden
+%union @{
+  long int n;
+  tree t;  /* @address@hidden is defined in @file{ptypes.h}.} */
address@hidden
+
+%requires @{
+  #define YYLTYPE YYLTYPE
+  typedef struct YYLTYPE
+  @{
+    int first_line;
+    int first_column;
+    int last_line;
+    int last_column;
+    char *filename;
+  @} YYLTYPE;
address@hidden
+
+%provides @{
+  void trace_token (enum yytokentype token, YYLTYPE loc);
address@hidden
+
+%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
 
address@hidden
+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},
address@hidden, 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:
address@hidden, @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:
+
address@hidden
+%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>
address@hidden smallexample
+
address@hidden
+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 @address@hidden@}
-Specifies code to be inserted into the code file after the contents of the
-header file.
address@hidden of Symbols, ,%requires}.
address@hidden deffn
-
address@hidden {Directive} %provides @address@hidden@}
-Specifies code to be inserted both into the header file (if generated;
address@hidden of Symbols, ,%defines}) and into the code file after any
-Bison-generated definitions.
address@hidden of Symbols, ,%requires}.
address@hidden deffn
-
address@hidden {Directive} %requires @address@hidden@}
-Specifies code to be inserted both into the header file (if generated;
address@hidden 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,
address@hidden@address@hidden@}}, for most purposes.
+For Java, it inserts code into the parser class.
 
 @cindex Prologue
 @findex %union
address@hidden %provides
address@hidden %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 @address@hidden@address@hidden (@pxref{Prologue, ,The Prologue})
+appearing after the first @code{%union @address@hidden@}} in a C/C++ based 
grammar
+file.
+While Bison will continue to support @address@hidden@address@hidden for 
backward
+compatibility, @code{%code @address@hidden@}} is cleaner as its functionality 
does
+not depend on its position in the grammar file relative to any
address@hidden @address@hidden@}}.
+Specifically, @code{%code @address@hidden@}} always inserts your @var{code} 
into
+the parser code file after the usual contents of the parser header file.
+
address@hidden Alternatives}.
address@hidden deffn
+
address@hidden {Directive} %code-top @address@hidden@}
+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.  */
address@hidden
-%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.  */
address@hidden
-%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.  */
address@hidden
-%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.
address@hidden
+For Java, @code{%code-top @address@hidden@}} is currently unused.
+
address@hidden Prologue
address@hidden %union
+Compare with @address@hidden@address@hidden appearing before the first
address@hidden @address@hidden@}} in a C/C++ based grammar file.
address@hidden @address@hidden@}} is cleaner as its functionality does not 
depend
+on its position in the grammar file relative to any
address@hidden @address@hidden@}}.
 
address@hidden, ,The Prologue}.
address@hidden Alternatives}.
 @end deffn
 
 @deffn {Directive} %debug
@@ -8490,6 +8700,18 @@ Bison declaration to assign a precedence
 @xref{Contextual Precedence, ,Context-Dependent Precedence}.
 @end deffn
 
address@hidden {Directive} %provides @address@hidden@}
+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.
+
address@hidden Alternatives}.
address@hidden 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
 
address@hidden {Directive} %requires @address@hidden@}
+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
address@hidden @address@hidden@}} 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.
+
address@hidden Prologue
address@hidden %union
+Compare with @address@hidden@address@hidden (@pxref{Prologue, ,The Prologue})
+appearing before the first @code{%union @address@hidden@}} in a C/C++ based
+grammar file.
+Unlike @address@hidden@address@hidden, @code{%requires @address@hidden@}} 
inserts your
address@hidden 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.
+
address@hidden Alternatives}.
address@hidden 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;