Jot, > Le 25 déc. 2020 à 04:28, Jot Dot <[email protected]> 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 <[email protected]> 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.
