Hi all,
> Le 27 déc. 2020 à 17:03, Akim Demaille a écrit :
>
> 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 introdu
regarding:
>> I wished Bison would spit out prototypes in the Parser class for each merge
>> routine
>> in the form:
>>
>> class Parser
>> { ...
>> ...
>> YYSTYPE stmtMerge(YYSTYPE y0, YYSTYPE y1); // One for each different merge
>> routine used
>> };
>>
>> and we just supply the implementati
Jot,
Sorry for not answering faster. I don't have enough time :(
I hope that meanwhile you managed to get your project move forward.
> Le 1 janv. 2021 à 23:32, Jot Dot a écrit :
>
>>> The incoming arguments are ok but there is no parsing context provided.
>>> It would be (to me) a quite useful
Hi Jot,
> Le 1 janv. 2021 à 23:32, Jot Dot a écrit :
>
> But, in my defence:
>***
>*** That wasn't what I was asking for all this time ***
>***
Ok :)
>> The else-cla
> Jot, as I have already stated several times, your merger is *typed*,
> which is an undocumented feature. The signature of your merger,
> as mentioned several times in my messages, should not be
>
> YYSTYPE stmtMerge(YYSTYPE x0, YYSTYPE x1)
>
> but
>
> gen::index_t stmtMerge(YYSTYPE x0, YYSTYP
Jot,
> Le 30 déc. 2020 à 10:18, Jot Dot a écrit :
>
>>> I get the same yyuserMerge as before. This time, it is using
>>> the new type of the rule that the merge is in (%type rule)
>>>
>>> case 1: yy0->index = stmtMerge (*yy0, *yy1); break;
>>
>> Which is good. That is what is expected.
>
>
recap: me looking for a working glr solution:
>> Alright. I took out the 'api.value.type union' and put in:
>> %union {
>> gen::index_t index;
>> merge_t merge; // A struct to hold my merge info
>> }
>>
>> All my tokens are of the form: %token tok1 tok2 tok3 ...
>> All my rules are of th
Hi Jot,
> Le 28 déc. 2020 à 10:09, Jot Dot a écrit :
>
> I'm not trying to irritate you with all of this.
I'm sure you are not.
> Alright. I took out the 'api.value.type union' and put in:
> %union {
> gen::index_t index;
> merge_t merge; // A struct to hold my merge info
> }
>
> All
I'm not trying to irritate you with all of this.
I probably starting to at this point but I'm really not trying to :)
If I must wait for some update then I will have to accept that.
I'm trying to convert over to *any glr form* that currently works.
> The code works when api.value.type union is no
Jot,
> Le 27 déc. 2020 à 22:31, Jot Dot a écrit :
>
> BTW: I'm using: Bison 3.7.1
>
>>> Assuming I have something simple like the following:
>>> %token IDENTIFIER
>>> %type subrule expr
>>
>> Which means that you are probably using "api.value.type variant". Which does
>
> *Sigh*
> That's w
BTW: I'm using: Bison 3.7.1
>> Assuming I have something simple like the following:
>> %token IDENTIFIER
>> %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 sh
Jot,
> Le 25 déc. 2020 à 04:28, Jot Dot 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; //
Hi Jot,
> Le 25 déc. 2020 à 04:28, Jot Dot a écrit :
>
> I'm using %glr-parser and ran into a snag with the %merge feature.
>
> I figure I must be misinterpreting something along the way.
> I think I've done what the docs say:
> https://www.gnu.org/software/bison/manual/html_node/Merging-GLR-Pa
I'm using %glr-parser and ran into a snag with the %merge feature.
I figure I must be misinterpreting something along the way.
I think I've done what the docs say:
https://www.gnu.org/software/bison/manual/html_node/Merging-GLR-Parses.html
Everything compiles fine except one bison generated line
14 matches
Mail list logo
