Jot, > Le 27 déc. 2020 à 22:31, Jot Dot <jot...@shaw.ca> a écrit : > > BTW: I'm using: Bison 3.7.1 > >>> Assuming I have something simple like the following: >>> %token <some_type> IDENTIFIER >>> %type <some_type> subrule expr >> >> Which means that you are probably using "api.value.type variant". Which does > > *Sigh* > That's why I was wondering what I was doing wrong. > I know I must use POD. > I should have also included in the lines above (which I use): > %define api.value.type union
Ok, this should have worked. This is a limitation in the current releases. I can prepare a tarball with a fix in the near future for this if you're interested. >> Your problem follows from the fact that there is support for "typed" mergers. > > I guess the question is "What am I doing wrong that is triggering this "typed" > merger feature? I'd like to just use POD, since the underlying type for > my "gen::index_t" is simply an unsigned short. You are not doing anything wrong, Bison is. Support for api.value.type union missed the case of the mergers. >> + 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); > >> 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. > > Ok. I'm using Bison 3.7.1 I'm assuming your pasted code is recent as well? Just read carefully my email, everything is in it. > I see the output is "yylval = " but I am using the C++ variant which I believe > implies %pure and thus yylval is undefined. Note that in my pasted code, the > difference is is yy0 is both lhs and an arg to the user's merge call. Note also that I wrote (and you quoted) "the names have changed since then". But the logic is the same. That's in src/output.c. > Are these few test cases enabled and working properly? > I mean, my code is trying to treat a type as a variable! > I can't see anything compiling at all when using this feature. The code works when api.value.type union is not used, for instance when you use %union. >> 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 agree. Especially in the case of POD.. The nature of the data (POD or object) is irrelevant here. The question is really that currently there are two signatures for mergers: untyped: (YYSTYPE, YYSTYPE) -> YYSTYPE typed: (YYSTYPE, YYSTYPE) -> gen::index_t The typed signature has two problems: (a) it is badly implemented in the case of api.value.type=union, and (b) I don't understand why the typed alternative is not (gen::index_t, gen::index_t) -> gen::index_t You did not provide the implementation of your merger, I'd like to see it. Cheers!