Re: %merge confusion

[Akim Demaille]

Jot,

> Le 25 déc. 2020 à 04:28, Jot Dot <jotdot@shaw.ca> a écrit :
> 
> This is the resultant code generated by bison:
> 
> static void
> yyuserMerge (int yyn, YYSTYPE* yy0, YYSTYPE* yy1)
> {
>  YYUSE (yy0);
>  YYUSE (yy1);
> 
>  switch (yyn)
>    {
>  case 1: yy0->gen::index_t = stmtMerge (*yy0, *yy1); break; // My only 
> compile error :(
> 
>      default: break;
>    }
> }

Your problem follows from the fact that there is support for "typed" mergers.

FWIW, I was unaware of this feature (the fact that the merge functions are 
"typed").  This is undocumented, yet dates back from the initial introduction 
of GLR in Bison:

commit 676385e29c4aedfc05d20daf1ef20cd4ccc84856
Author: Paul Hilfinger <Hilfinger@CS.Berkeley.EDU>
Date:   Fri Jun 28 02:26:44 2002 +0000

    Initial check-in introducing experimental GLR parsing.  See entry in
    ChangeLog dated 2002-06-27 from Paul Hilfinger for details.

+void
+merger_output (FILE *out)
+{
+  int n;
+  merger_list* p;
+
+  fputs ("m4_define([b4_mergers], \n[[", out);
+  for (n = 1, p = merge_functions; p != NULL; n += 1, p = p->next) 
+    {
+      if (p->type[0] == '\0') 
+       fprintf (out, "  case %d: yyval = %s (*yy0, *yy1); break;\n",
+                n, p->name);
+      else
+       fprintf (out, "  case %d: yyval.%s = %s (*yy0, *yy1); break;\n",
+                n, p->type, p->name);
+    }
+  fputs ("]])\n\n", out);
+}

The else-clause (which is the one that introduces the yy0->TYPE (the names have 
changed since then) which is broken in your case) is undocumented, but there 
are a few test cases in the test suite.

I don't understand the design of this feature: why is it asymmetrical?  I mean: 
the input arguments are "untyped" (they are YYSTYPE, i.e., the union of all the 
types used in the grammar), while the output is the exact type of the current 
lhs.  I would have used the exact type in both cases.

I'd like to fix that, but I'm not sure how to do that in a backward compatible 
way.