Re: [SPAM] Re: proposal: simplify prologue alternatives into %code

[Joel E. Denny]

On Mon, 8 Jan 2007, Joel E. Denny wrote:

> On Mon, 8 Jan 2007, Paul Eggert wrote:
> 
> > "Joel E. Denny" <address@hidden> writes:
> > 
> > > I believe %define "NAME" "VALUE" is currently only used for the C++ 
> > > skeletons.  Should we continue to support it for backward compatibility 
> > > but deprecate it in favor of the unquoted NAME form?  Or can we just get 
> > > rid of it?
> > 
> > The latter, I'd say.  I don't think anybody but ourselves is using
> > this feature.  (I assume it's not documented.)
> 
> It appears in the C++ examples in the documentation.  Are we concerned 
> with backward compatibility for the C++ skeletons yet?

I'll just play it safe for now.  I committed the following.

Index: ChangeLog
===================================================================
RCS file: /sources/bison/bison/ChangeLog,v
retrieving revision 1.1654
diff -p -u -r1.1654 ChangeLog
--- ChangeLog   8 Jan 2007 22:06:55 -0000       1.1654
+++ ChangeLog   9 Jan 2007 01:12:05 -0000
@@ -1,5 +1,32 @@
 2007-01-08  Joel E. Denny  <address@hidden>
 
+       Remove quotes from variables names in %define directives and from
+       qualifiers in %code directives, and restrict the characters that are
+       allowed in them to M4-friendly ones.  For %define, continue to support
+       the quoted form as a deprecated feature.  Discussed starting at
+       <http://lists.gnu.org/archive/html/bison-patches/2007-01/msg00023.html>.
+       * NEWS (2.3a+): Add entry for the change to %define.  Update entry for
+       %code.
+       * doc/bison.texinfo (Prologue Alternatives): Update.
+       (Bison Declaration Summary): In %defines entry, update mention of
+       `%code requires' and `%code provides'.
+       (C++ Location Values): Update %define uses.
+       (Calc++ Parser Interface): Likewise.
+       (Calc++ Parser): Likewise, and update `%code requires' uses.
+       (Bison Symbols): Update %code documentation.
+       * src/parse-gram.y (prologue_declaration): For %define variables, use
+       `variable' instead of `STRING'.
+       (grammar_declaration): For %code qualifiers, use `ID' instead of
+       `STRING'.
+       (variable): New nonterminal that takes an `ID' or a `STRING'.
+       * tests/actions.at (_AT_CHECK_PRINTER_AND_DESTRUCTOR): Update %code
+       and %define uses.
+       * tests/calc.at (_AT_DATA_CALC_Y): Update %define use.
+       * tests/input.at (Reject unused %code qualifiers): Update %code uses.
+       (%define errors): Update %define uses.
+
+2007-01-08  Joel E. Denny  <address@hidden>
+
        * src/parse-gram.y (prologue_declaration): Use MUSCLE_INSERT_STRING
        instead of muscle_insert for %define values so that M4-special
        characters are replaced with digraphs.
Index: NEWS
===================================================================
RCS file: /sources/bison/bison/NEWS,v
retrieving revision 1.170
diff -p -u -r1.170 NEWS
--- NEWS        5 Jan 2007 08:14:44 -0000       1.170
+++ NEWS        9 Jan 2007 01:12:05 -0000
@@ -16,23 +16,28 @@ Changes in version 2.3a+ (????-??-??):
 
     %defines "parser.h"
 
-* The `=' that used to be required in the following declarations is now
+* The `=' that used to be required in the following directives is now
   deprecated:
 
     %file-prefix "parser"
     %name-prefix "c_"
     %output "parser.c"
 
+* The quotes around NAME that used to be required in the following directive
+  are now deprecated:
+
+    %define NAME "VALUE"
+
 * Bison 2.3a provided a new set of directives as a more flexible alternative to
   the traditional Yacc prologue blocks.  Those have now been consolidated into
   a single %code directive with an optional qualifier field, which identifies
   the purpose of the code and thus the location(s) where Bison should generate
   it:
 
-    1. `%code            {CODE}' replaces `%after-header  {CODE}'
-    2. `%code "requires" {CODE}' replaces `%start-header  {CODE}'
-    3. `%code "provides" {CODE}' replaces `%end-header    {CODE}'
-    4. `%code "top"      {CODE}' replaces `%before-header {CODE}'
+    1. `%code          {CODE}' replaces `%after-header  {CODE}'
+    2. `%code requires {CODE}' replaces `%start-header  {CODE}'
+    3. `%code provides {CODE}' replaces `%end-header    {CODE}'
+    4. `%code top      {CODE}' replaces `%before-header {CODE}'
 
   See the %code entries in `Appendix A Bison Symbols' in the Bison manual for a
   summary of the new functionality.  See the new section `Prologue
Index: doc/bison.texinfo
===================================================================
RCS file: /sources/bison/bison/doc/bison.texinfo,v
retrieving revision 1.218
diff -p -u -r1.218 bison.texinfo
--- doc/bison.texinfo   5 Jan 2007 08:14:44 -0000       1.218
+++ doc/bison.texinfo   9 Jan 2007 01:12:09 -0000
@@ -2681,9 +2681,9 @@ feature test macros can affect the behav
 @cindex Prologue Alternatives
 
 @findex %code
address@hidden %code "requires"
address@hidden %code "provides"
address@hidden %code "top"
address@hidden %code requires
address@hidden %code provides
address@hidden %code top
 (The prologue alternatives described here are experimental.
 More user feedback will help to determine whether they should become permanent
 features.)
@@ -2694,7 +2694,7 @@ As an alternative, Bison provides a %cod
 field, which identifies the purpose of the code and thus the location(s) where
 Bison should generate it.
 For C/C++, the qualifier can be omitted for the default location, or it can be
-"requires", "provides", or "top".
address@hidden, @code{provides}, or @code{top}.
 @xref{Table of Symbols,,Bison Symbols}.
 
 Look again at the example of the previous section:
@@ -2743,17 +2743,17 @@ In that case, the second kind of @var{Pr
 This behavior is not intuitive.
 
 To avoid this subtle @code{%union} dependency, rewrite the example using a
address@hidden "top"} and an unqualified @code{%code}.
address@hidden top} and an unqualified @code{%code}.
 Let's go ahead and add the new @code{YYLTYPE} definition and the
 @code{trace_token} prototype at the same time:
 
 @smallexample
-%code "top" @{
+%code top @{
   #define _GNU_SOURCE
   #include <stdio.h>
 
   /* WARNING: The following code really belongs
-   * in a %code "requires"; see below.  */
+   * in a `%code requires'; see below.  */
 
   #include "ptypes.h"
   #define YYLTYPE YYLTYPE
@@ -2782,12 +2782,12 @@ Let's go ahead and add the new @code{YYL
 @end smallexample
 
 @noindent
-In this way, @code{%code "top"} and the unqualified @code{%code} achieve the
-same functionality as the two kinds of @var{Prologue} sections, but it's always
+In this way, @code{%code top} and the unqualified @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 @code{%code "top"} block above logically contains two parts.
+The @code{%code top} block above logically contains two parts.
 The first two lines before the warning need to appear near the top of the
 parser source code file.
 The first line after the warning is required by @code{YYSTYPE} and thus also
@@ -2798,18 +2798,18 @@ before the @code{YYSTYPE} definition in 
 The @code{YYLTYPE} definition should also appear in the parser header file to
 override the default @code{YYLTYPE} definition there.
 
-In other words, in the @code{%code "top"} block above, all but the first two
+In other words, in the @code{%code top} block above, all but the first two
 lines are dependency code required by the @code{YYSTYPE} and @code{YYLTYPE}
 definitions.
-Thus, they belong in one or more @code{%code "requires"}:
+Thus, they belong in one or more @code{%code requires}:
 
 @smallexample
-%code "top" @{
+%code top @{
   #define _GNU_SOURCE
   #include <stdio.h>
 @}
 
-%code "requires" @{
+%code requires @{
   #include "ptypes.h"
 @}
 %union @{
@@ -2817,7 +2817,7 @@ Thus, they belong in one or more @code{%
   tree t;  /* @address@hidden is defined in @file{ptypes.h}.} */
 @}
 
-%code "requires" @{
+%code requires @{
   #define YYLTYPE YYLTYPE
   typedef struct YYLTYPE
   @{
@@ -2842,20 +2842,20 @@ Thus, they belong in one or more @code{%
 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 source code file and the parser header file.
-(By the same reasoning, @code{%code "requires"} would also be the appropriate
+(By the same reasoning, @code{%code requires} would also be the appropriate
 place to write your own definition for @code{YYSTYPE}.)
 
 When you are writing dependency code for @code{YYSTYPE} and @code{YYLTYPE}, you
-should prefer @code{%code "requires"} over @code{%code "top"} regardless of
-whether you instruct Bison to generate a parser header file.
+should prefer @code{%code requires} over @code{%code top} regardless of whether
+you instruct Bison to generate a parser header file.
 When you are writing code that you need Bison to insert only into the parser
 source code file and that has no special need to appear at the top of that
-file, you should prefer the unqualified @code{%code} over @code{%code "top"}.
+file, you should prefer the unqualified @code{%code} over @code{%code top}.
 These practices will make the purpose of each block of your code explicit to
 Bison and to other developers reading your grammar file.
 Following these practices, we expect the unqualified @code{%code} and
address@hidden "requires"} to be the most important of the four @var{Prologue}
-alternatives discussed in this section.
address@hidden requires} to be the most important of the four @var{Prologue}
+alternatives.
 
 At some point while developing your parser, you might decide to provide
 @code{trace_token} to modules that are external to your parser.
@@ -2863,19 +2863,19 @@ Thus, you might wish for Bison to insert
 header file and the parser source code file.
 Since this function is not a dependency required by @code{YYSTYPE} or
 @code{YYLTYPE}, it doesn't make sense to move its prototype to a
address@hidden "requires"}.
address@hidden requires}.
 More importantly, since it depends upon @code{YYLTYPE} and @code{yytokentype},
address@hidden "requires"} is not sufficient.
address@hidden requires} is not sufficient.
 Instead, move its prototype from the unqualified @code{%code} to a
address@hidden "provides"}:
address@hidden provides}:
 
 @smallexample
-%code "top" @{
+%code top @{
   #define _GNU_SOURCE
   #include <stdio.h>
 @}
 
-%code "requires" @{
+%code requires @{
   #include "ptypes.h"
 @}
 %union @{
@@ -2883,7 +2883,7 @@ Instead, move its prototype from the unq
   tree t;  /* @address@hidden is defined in @file{ptypes.h}.} */
 @}
 
-%code "requires" @{
+%code requires @{
   #define YYLTYPE YYLTYPE
   typedef struct YYLTYPE
   @{
@@ -2895,7 +2895,7 @@ Instead, move its prototype from the unq
   @} YYLTYPE;
 @}
 
-%code "provides" @{
+%code provides @{
   void trace_token (enum yytokentype token, YYLTYPE loc);
 @}
 
@@ -2914,7 +2914,7 @@ file and the parser source code file aft
 
 The above examples are careful to write directives in an order that reflects
 the layout of the generated parser source code and header files:
address@hidden "top"}, @code{%code "requires"}, @code{%code "provides"}, and 
then
address@hidden top}, @code{%code requires}, @code{%code provides}, and then
 @code{%code}.
 While your grammar files may generally be easier to read if you also follow
 this order, Bison does not require it.
@@ -2931,12 +2931,12 @@ For example, you may organize semantic-t
 type:
 
 @smallexample
-%code "requires" @{ #include "type1.h" @}
+%code requires @{ #include "type1.h" @}
 %union @{ type1 field1; @}
 %destructor @{ type1_free ($$); @} <field1>
 %printer @{ type1_print ($$); @} <field1>
 
-%code "requires" @{ #include "type2.h" @}
+%code requires @{ #include "type2.h" @}
 %union @{ type2 field2; @}
 %destructor @{ type2_free ($$); @} <field2>
 %printer @{ type2_print ($$); @} <field2>
@@ -2958,8 +2958,8 @@ think about all the low-level ordering i
 Instead, you should simply use these directives to label each block of your
 code according to its purpose and let Bison handle the ordering.
 @code{%code} is the most generic label.
-Move code to @code{%code "requires"}, @code{%code "provides"}, or
address@hidden "top"} as needed.
+Move code to @code{%code requires}, @code{%code provides}, or @code{%code top}
+as needed.
 
 @node Bison Declarations
 @subsection The Bison Declarations Section
@@ -4608,10 +4608,10 @@ typically needs to be able to refer to t
 and to the token type codes.  @xref{Token Values, ,Semantic Values of
 Tokens}.
 
address@hidden %code "requires"
address@hidden %code "provides"
-If you have declared @code{%code "requires"} or @code{%code "provides"}, the
-output header also contains their code.
address@hidden %code requires
address@hidden %code provides
+If you have declared @code{%code requires} or @code{%code provides}, the output
+header also contains their code.
 @xref{Table of Symbols, ,%code}.
 @end deffn
 
@@ -7540,7 +7540,7 @@ Symbols}.
 @c - %locations
 @c - class Position
 @c - class Location
address@hidden - %define "filename_type" "const symbol::Symbol"
address@hidden - %define filename_type "const symbol::Symbol"
 
 When the directive @code{%locations} is used, the C++ parser supports
 location tracking, see @ref{Locations, , Locations Overview}.  Two
@@ -7552,7 +7552,7 @@ and a @code{location}, a range composed 
 The name of the file.  It will always be handled as a pointer, the
 parser will never duplicate nor deallocate it.  As an experimental
 feature you may change it to @address@hidden using @samp{%define
-"filename_type" "@var{type}"}.
+filename_type "@var{type}"}.
 @end deftypemethod
 
 @deftypemethod {position} {unsigned int} line
@@ -7616,7 +7616,7 @@ Move @code{begin} onto @code{end}.
 The output files @address@hidden and @address@hidden
 declare and define the parser class in the namespace @code{yy}.  The
 class name defaults to @code{parser}, but may be changed using
address@hidden "parser_class_name" "@var{name}"}.  The interface of
address@hidden parser_class_name "@var{name}"}.  The interface of
 this class is detailed below.  It can be extended using the
 @code{%parse-param} feature: its semantics is slightly changed since
 it describes an additional member of the parser class, and an
@@ -7869,11 +7869,11 @@ the grammar for.
 %language "C++"                          /*  -*- C++ -*- */
 %require "@value{VERSION}"
 %defines
-%define "parser_class_name" "calcxx_parser"
+%define parser_class_name "calcxx_parser"
 @end example
 
 @noindent
address@hidden %code "requires"
address@hidden %code requires
 Then come the declarations/inclusions needed to define the
 @code{%union}.  Because the parser uses the parsing driver and
 reciprocally, both cannot include the header of the other.  Because the
@@ -7884,7 +7884,7 @@ use a forward declaration of the driver.
 
 @comment file: calc++-parser.yy
 @example
-%code "requires" @{
+%code requires @{
 # include <string>
 class calcxx_driver;
 @}
@@ -8664,7 +8664,7 @@ More user feedback will help to determin
 feature.)
 @end deffn
 
address@hidden {Directive} %code "@var{qualifier}" @address@hidden@}
address@hidden {Directive} %code @var{qualifier} @address@hidden@}
 This is the qualified form of the @code{%code} directive.
 If you need to specify location-sensitive verbatim @var{code} that does not
 belong at the default location selected by the unqualified @code{%code} form,
@@ -8675,8 +8675,8 @@ where Bison should generate it.
 Not all values of @var{qualifier} are available for all target languages:
 
 @itemize @bullet
address@hidden %code "requires"
address@hidden "requires"
address@hidden %code requires
address@hidden requires
 
 @itemize @bullet
 @item Language(s): C, C++
@@ -8691,8 +8691,8 @@ and @code{YYLTYPE} definitions.
 before the Bison-generated @code{YYSTYPE} and @code{YYLTYPE} definitions.
 @end itemize
 
address@hidden "provides"
address@hidden %code "provides"
address@hidden provides
address@hidden %code provides
 
 @itemize @bullet
 @item Language(s): C, C++
@@ -8704,20 +8704,20 @@ declarations that should be provided to 
 the Bison-generated @code{YYSTYPE}, @code{YYLTYPE}, and token definitions.
 @end itemize
 
address@hidden "top"
address@hidden %code "top"
address@hidden top
address@hidden %code top
 
 @itemize @bullet
 @item Language(s): C, C++
 
address@hidden Purpose: The unqualified @code{%code} or @code{%code "requires"} 
should
-usually be more appropriate than @code{%code "top"}.
address@hidden Purpose: The unqualified @code{%code} or @code{%code requires} 
should
+usually be more appropriate than @code{%code top}.
 However, occasionally it is necessary to insert code much nearer the top of the
 parser source code file.
 For example:
 
 @smallexample
-%code "top" @{
+%code top @{
   #define _GNU_SOURCE
   #include <stdio.h>
 @}
@@ -8726,8 +8726,8 @@ For example:
 @item Location(s): Near the top of the parser source code file.
 @end itemize
 @ignore
address@hidden "imports"
address@hidden %code "imports"
address@hidden imports
address@hidden %code imports
 
 @itemize @bullet
 @item Language(s): Java
Index: src/parse-gram.y
===================================================================
RCS file: /sources/bison/bison/src/parse-gram.y,v
retrieving revision 1.111
diff -p -u -r1.111 parse-gram.y
--- src/parse-gram.y    8 Jan 2007 22:06:55 -0000       1.111
+++ src/parse-gram.y    9 Jan 2007 01:12:09 -0000
@@ -190,9 +190,9 @@ static int current_prec = 0;
 %printer { fprintf (stderr, "{\n%s\n}", $$); }
         braceless content.opt "{...}" "%{...%}" EPILOGUE
 
-%type <uniqstr> TYPE ID ID_COLON
+%type <uniqstr> TYPE ID ID_COLON variable
 %printer { fprintf (stderr, "<%s>", $$); } TYPE
-%printer { fputs ($$, stderr); } ID
+%printer { fputs ($$, stderr); } ID variable
 %printer { fprintf (stderr, "%s:", $$); } ID_COLON
 
 %type <integer> INT
@@ -232,10 +232,8 @@ prologue_declaration:
       code_scanner_last_string_free ();
     }
 | "%debug"                         { debug_flag = true; }
-| "%define" STRING content.opt
+| "%define" variable content.opt
     {
-      /* FIXME: Special characters in $2 may break %define.
-         For example: `['.  */
       char const name_prefix[] = "percent_define_";
       char *name = xmalloc (sizeof name_prefix + strlen ($2));
       strcpy (name, name_prefix);
@@ -326,10 +324,8 @@ grammar_declaration:
       muscle_code_grow ("percent_code", $2, @2);
       code_scanner_last_string_free ();
     }
-| "%code" STRING braceless
+| "%code" ID braceless
     {
-      /* FIXME: Special characters in $2 may break %code.
-         For example: `['.  */
       char const name_prefix[] = "percent_code_";
       char *name = xmalloc (sizeof name_prefix + strlen ($2));
       strcpy (name, name_prefix);
@@ -535,9 +531,14 @@ rhs:
 ;
 
 
-/*---------------*
- | content.opt.  |
- *--------------*/
+/*----------------------------*
+ | variable and content.opt.  |
+ *---------------------------*/
+
+variable:
+  ID
+  | STRING { $$ = uniqstr_new ($1); } /* deprecated and not M4-friendly */
+  ;
 
 /* Some content or "1" by default. */
 content.opt:
Index: tests/actions.at
===================================================================
RCS file: /sources/bison/bison/tests/actions.at,v
retrieving revision 1.77
diff -p -u -r1.77 actions.at
--- tests/actions.at    5 Jan 2007 08:14:44 -0000       1.77
+++ tests/actions.at    9 Jan 2007 01:12:10 -0000
@@ -178,7 +178,7 @@ m4_if([$1$2$3], $[1]$[2]$[3], [],
 # helping macros.  So don't put any directly in the Bison file.
 AT_BISON_OPTION_PUSHDEFS([$5])
 AT_DATA_GRAMMAR([[input.y]],
-[[%code "requires" {
+[[%code requires {
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -196,8 +196,8 @@ m4_ifval([$6], [%union
 {
   int ival;
 }])
-AT_LALR1_CC_IF([%define "global_tokens_and_yystype"])
-m4_ifval([$6], [[%code "provides" {]], [[%code {]])
+AT_LALR1_CC_IF([%define global_tokens_and_yystype])
+m4_ifval([$6], [[%code provides {]], [[%code {]])
 AT_LALR1_CC_IF([typedef yy::location YYLTYPE;])
 [static int yylex (]AT_LEX_FORMALS[);
 ]AT_LALR1_CC_IF([], [static void yyerror (const char *msg);])
Index: tests/calc.at
===================================================================
RCS file: /sources/bison/bison/tests/calc.at,v
retrieving revision 1.103
diff -p -u -r1.103 calc.at
--- tests/calc.at       1 Jan 2007 00:42:21 -0000       1.103
+++ tests/calc.at       9 Jan 2007 01:12:10 -0000
@@ -41,7 +41,7 @@ AT_DATA_GRAMMAR([calc.y],
 [[/* Infix notation calculator--calc */
 ]$4
 AT_SKEL_CC_IF(
-[%define "global_tokens_and_yystype"])[
+[%define global_tokens_and_yystype])[
 %{
 #include <stdio.h>
 
Index: tests/input.at
===================================================================
RCS file: /sources/bison/bison/tests/input.at,v
retrieving revision 1.73
diff -p -u -r1.73 input.at
--- tests/input.at      8 Jan 2007 22:06:55 -0000       1.73
+++ tests/input.at      9 Jan 2007 01:12:10 -0000
@@ -710,81 +710,81 @@ AT_CLEANUP
 AT_SETUP([Reject unused %code qualifiers])
 
 AT_DATA([input-c.y],
-[[%code "" {}
-%code "bad" {}
-%code "bad" {}
+[[%code q {}
+%code bad {}
+%code bad {}
 %%
 start: ;
 ]])
 AT_CHECK([[bison input-c.y]], [0], [],
-[[input-c.y:1.7-8: warning: %code qualifier `' is not used
-input-c.y:2.7-11: warning: %code qualifier `bad' is not used
-input-c.y:3.7-11: warning: %code qualifier `bad' is not used
+[[input-c.y:1.7: warning: %code qualifier `q' is not used
+input-c.y:2.7-9: warning: %code qualifier `bad' is not used
+input-c.y:3.7-9: warning: %code qualifier `bad' is not used
 ]])
 
 AT_DATA([input-c-glr.y],
-[[%code "" {}
-%code "bad" {}
- %code "bad" {}
+[[%code q {}
+%code bad {}
+ %code bad {}
 %%
 start: ;
 ]])
 AT_CHECK([[bison input-c-glr.y]], [0], [],
-[[input-c-glr.y:1.7-8: warning: %code qualifier `' is not used
-input-c-glr.y:2.7-11: warning: %code qualifier `bad' is not used
-input-c-glr.y:3.8-12: warning: %code qualifier `bad' is not used
+[[input-c-glr.y:1.7: warning: %code qualifier `q' is not used
+input-c-glr.y:2.7-9: warning: %code qualifier `bad' is not used
+input-c-glr.y:3.8-10: warning: %code qualifier `bad' is not used
 ]])
 
 AT_DATA([input-c++.y],
-[[%code "" {}
-%code "bad" {}
- %code "" {}
+[[%code q {}
+%code bad {}
+ %code q {}
 %%
 start: ;
 ]])
 AT_CHECK([[bison input-c++.y]], [0], [],
-[[input-c++.y:1.7-8: warning: %code qualifier `' is not used
-input-c++.y:2.7-11: warning: %code qualifier `bad' is not used
-input-c++.y:3.8-9: warning: %code qualifier `' is not used
+[[input-c++.y:1.7: warning: %code qualifier `q' is not used
+input-c++.y:2.7-9: warning: %code qualifier `bad' is not used
+input-c++.y:3.8: warning: %code qualifier `q' is not used
 ]])
 
 AT_DATA([input-c++-glr.y],
-[[%code "bad" {}
-%code "" {}
-%code "" {}
+[[%code bad {}
+%code q {}
+%code q {}
 %%
 start: ;
 ]])
 AT_CHECK([[bison input-c++-glr.y]], [0], [],
-[[input-c++-glr.y:1.7-11: warning: %code qualifier `bad' is not used
-input-c++-glr.y:2.7-8: warning: %code qualifier `' is not used
-input-c++-glr.y:3.7-8: warning: %code qualifier `' is not used
+[[input-c++-glr.y:1.7-9: warning: %code qualifier `bad' is not used
+input-c++-glr.y:2.7: warning: %code qualifier `q' is not used
+input-c++-glr.y:3.7: warning: %code qualifier `q' is not used
 ]])
 
 AT_DATA([special-char-@@.y],
-[[%code "bad" {}
-%code "" {}
-%code "" {}
+[[%code bad {}
+%code q {}
+%code q {}
 %%
 start: ;
 ]])
 AT_CHECK([[bison special-char-@@.y]], [0], [],
-[[special-char-@@.y:1.7-11: warning: %code qualifier `bad' is not used
-special-char-@@.y:2.7-8: warning: %code qualifier `' is not used
-special-char-@@.y:3.7-8: warning: %code qualifier `' is not used
+[[special-char-@@.y:1.7-9: warning: %code qualifier `bad' is not used
+special-char-@@.y:2.7: warning: %code qualifier `q' is not used
+special-char-@@.y:3.7: warning: %code qualifier `q' is not used
 ]])
 
 AT_DATA([special-char-@:>@.y],
-[[%code "bad" {}
-%code "" {}
-%code "" {}
+[[%code bad {}
+%code q {}
+%code q {}
 %%
 start: ;
 ]])
 AT_CHECK([[bison special-char-@:>@.y]], [0], [],
-[[special-char-@:>@.y:1.7-11: warning: %code qualifier `bad' is not used
-special-char-@:>@.y:2.7-8: warning: %code qualifier `' is not used
-special-char-@:>@.y:3.7-8: warning: %code qualifier `' is not used
+[[special-char-@:>@.y:1.7-9: warning: %code qualifier `bad' is not used
+special-char-@:>@.y:2.7: warning: %code qualifier `q' is not used
+special-char-@:>@.y:3.7: warning: %code qualifier `q' is not used
 ]])
 
 AT_CLEANUP
@@ -797,23 +797,23 @@ AT_CLEANUP
 AT_SETUP([%define errors])
 
 AT_DATA([input.y],
-[[%define "var" "value1"
-%define "var" "value1"
- %define "var" "value2"
-%define "special1" "@:>@"
-%define "special2" "@<:@"
+[[%define var "value1"
+%define var "value1"
+ %define var "value2"
+%define special1 "@:>@"
+%define special2 "@<:@"
 %%
 start: ;
 ]])
 
 AT_CHECK([[bison input.y]], [0], [],
-[[input.y:2.9-13: warning: %define variable `var' redefined
-input.y:3.10-14: warning: %define variable `var' redefined
-input.y:1.9-13: warning: %define variable `var' is not used
-input.y:2.9-13: warning: %define variable `var' is not used
-input.y:3.10-14: warning: %define variable `var' is not used
-input.y:4.9-18: warning: %define variable `special1' is not used
-input.y:5.9-18: warning: %define variable `special2' is not used
+[[input.y:2.9-11: warning: %define variable `var' redefined
+input.y:3.10-12: warning: %define variable `var' redefined
+input.y:1.9-11: warning: %define variable `var' is not used
+input.y:2.9-11: warning: %define variable `var' is not used
+input.y:3.10-12: warning: %define variable `var' is not used
+input.y:4.9-16: warning: %define variable `special1' is not used
+input.y:5.9-16: warning: %define variable `special2' is not used
 ]])
 
 AT_CLEANUP