Assertion failure due to double destruction in Bison v3.0

[Paolo Simone Gasparello]

I think I've found an issue with the lalr1.cc generator.

The code: http://pastebin.com/6kTvLRwr

That is a simple calculator parser. When a string that refers to an invalid
identifier is given to the parser, an assertion failure is raised.



The assertion that fails is:

YYASSERT (yytname_ == typeid (T).name ());

in the method variant::as.

It fails because yytname_  is null, while typeid (T).name () is "double".

It is generated the second time the local variable yylhs is destroyed in
the parse method. It seems to me that there is a double destruction of that
variable. The first destruction runs fine. It occurs in the code that
handles the syntax error:

  /*---------------------------------------------------.
  | yyerrorlab -- error raised explicitly by YYERROR.  |
  `---------------------------------------------------*/
  yyerrorlab:

    /* Pacify compilers like GCC when the user code never invokes
       YYERROR and the label yyerrorlab therefore never appears in user
       code.  */
    if (false)
      goto yyerrorlab;
    yyerror_range[1].location = yystack_[yylen - 1].location;
    /* $$ was initialized before running the user action.  */
    YY_SYMBOL_PRINT ("Error: discarding", yylhs);
    yylhs.~stack_symbol_type();
<-----------------------------------------------------------------------
Here the destructor is manually called, and value.yytname_ is set to
 YY_NULL by variant::destroy, but  typeid (T).name () is kept as "double"
    /* Do not reclaim the symbols of the rule whose action triggered
       this YYERROR.  */
    yypop_ (yylen);
    yylen = 0;
    goto yyerrlab1;


After that, when the parse function returns 1, the yylhs local variable is
destroyed again, because it goes out of scope. Thus, during the stack
cleanup, the assertion YYASSERT (yytname_ == typeid (T).name ()); fails.

-- 
Paolo Gasparello