Bison C++ mid-rule value lost with variants - c++

Question

I'm using Bison with lalr1.cc skeleton to generate C++ parser and api.value.type variant. I tried to use mid-rule action to return value that will be used in further semantic actions, but it appears that the value on stack becomes zero. Below is an example.
parser.y:
%require "3.0"
%skeleton "lalr1.cc"
%defines
%define api.value.type variant
%code {
#include <iostream>
#include "parser.yy.hpp"
extern int yylex(yy::parser::semantic_type * yylval);
}
%token <int> NUM
%%
expr: NUM | expr { $<int>$ = 42; } '+' NUM { std::cout << $<int>2 << std::endl; };
%%
void yy::parser::error(const std::string & message){
std::cerr << message << std::endl;
}
int main(){
yy::parser p;
return p.parse();
}
lexer.flex:
%option noyywrap
%option nounput
%option noinput
%{
#include "parser.yy.hpp"
typedef yy::parser::token token;
#define YY_DECL int yylex(yy::parser::semantic_type * yylval)
%}
%%
[ \n\t]+
[0-9]+ {
yylval->build(atoi(yytext));
return token::NUM;
}
. {
return yytext[0];
}
compiling:
bison -o parser.yy.cpp parser.y
flex -o lexer.c lexer.flex
g++ parser.yy.cpp lexer.c -O2 -Wall -o parser
Simple input like 2+2 should print value 42 but instead appears 0. When variant type is changed to %union, the printed value is as it should be. For a workaround I've been using marker actions with $<type>-n to get deeper values from stack, but that approach can reduce legibility and maintainability.
I've read in the generated source that when using variant type, the default action { $$ = $1 } is not executed. Is it an example of that behavior or is it a bug?

Answer 1

I vote for "bug". It does not have to do with the absence of the default action.
I traced execution through to the point where it attempts to push the value of the MRA onto the stack. However, it does not get the correct type for the MRA, with the result that the call to yypush_ does nothing, which is clearly not the desired action.
If I were you, I'd report the problem.

Answer 2

This was indeed a bug in Bison 3.0.5, but using $<foo>1 is also intrinsically wrong (yet there was no alternative!).
Consider:
// 1.y
%nterm <int> exp
%%
exp: { $<int>$ = 42; } { $$ = $<int>1; }
It is translated into something like:
// 2.y
%nterm <int> exp
%%
#1: %empty { $<int>$ = 42; }
exp: #1 { $$ = $<int>1; }
What is wrong here is that we did not tell Bison what the type of the semantic value of #1 is, so it will not be able to handle this semantic value correctly (typically, no %printer and no %destructor will be applied). Worse yet: here, because it does not know what value is actually stored here, it is unable to manipulate it properly: it does not know how to copy it from the local variable $$ to the stack, that's why the value was lost. (In C, the bits of the semantic value are copied blindly, so it works. In C++ with Bison variants, we use the exact assignment/copy operators corresponding to the current type, which requires to know what the type is.)
Clearly a better translation would have been to have #1 be given a type:
// 3.y
%nterm <int> exp #1
%%
#1: %empty { $$ = 42; }
exp: #1 { $$ = $1; }
which is actually what anybody would have written.
Thanks to your question, Bison 3.1 now features typed midrule actions:
// 4.y
%nterm <int> exp
%%
exp: <int>{ $$ = 42; } { $$ = $1; }
Desugared, 4.y generates exactly as in 3.y.
See http://lists.gnu.org/archive/html/bug-bison/2017-06/msg00000.html and http://lists.gnu.org/archive/html/bug-bison/2018-06/msg00001.html for more details.