Re: Bison C++ mid-rule value lost with variants

[Piotr Marcińczyk]

Thanks for the workaround. Actually, I used marker tokens with actions
getting value from stack before the rule, e.g.:

%type <int> AnswerToLifeMarker

expr: expr AnswerToLifeMarker + NUM { std::cout << $2 << std::endl; };

AnswerToLifeMarker: { usePreviousExpr($<int>0); $$ = 42; };

​That's because I need a way to create and store labels for later jumps
between statements​ in generated code. So one global value is not
sufficient. I would need a separate stack for that - I tried this approach
and the code seemed more error prone and less maintainable.


​Best regards,

      Piotr Marcińczyk

2017-06-29 20:07 GMT+02:00 Kaz Kylheku <address@hidden>:

> On 29.06.2017 06:55, Piotr Marcińczyk wrote:
>
>> I supposedly found a bug in lalr1.cc skeleton with variant semantic type.
>> When using mid-rule action { $<type>$ = value; } to return a value that
>> will be used in further semantic actions, it appears that the value on
>> stack becomes zero. Tested with Bison version 3.0.4.
>>
>
> You probably need your code to work with Bison installations
> that don't have a fix for this (which is all of them, currently,
> except maybe yours).
>
> Could the workaround be as simple as:
>
>    /* plain old local variable, injected into yyparse */
>
>    { int whatever = 42; } + NUM { std::cout << whatever << std::endl; }
>
> Also, you can have a scratch space in your parser structure
> for carrying a value from one mid-rule action to another.
>
>    /* assumes %parse-param{your_parser_type *parser} */
>
>    { parser->stash = 42; } + NUM { std::cout << parser->stash <<
> std::endl: }
>
> I've done this latter sort of of thing.
>
> The parser structure is basically your "this" object in the entire
> parse job, and yyparse is its "method". :)
>
> Cheers ...
>
>