Re: Using api.token.constructor for tokens without arguments.

[Akim Demaille]

Hi!

> Le 25 août 2015 à 14:20, Slava Barinov <address@hidden> a écrit :
> 
> Hello,
> 
> I'm experimenting with bison+flex and met an issue: bison won't provide a
> token type info.  So the situation: I've got a calc++ example and started to
> simplify it. For example there are two operations + and - which will increase
> and decrease global variables (no arguments needed) so there are lines in
> lex.ll
> 
> "+"       return yy::parser::make_INC(loc);
> "-"       return yy::parser::make_DEC(loc);
> 
> and corresponding
> 
> %define api.token.constructor
> %define api.value.type variant
> %define parse.assert
>   ...
> 
> %token INC DEC
>   ...
> stmts:        stmt {};
>    |    stmts stmt {};
>    ;
> stmt:         op
>    ;
> op:        val_op
>    ;
> val_op:        INC {driver.addOp($1);}
>    |    DEC {driver.addOp($1);}
>    ;
> 
>  in parse.yy.
> 
>  Parser generation is fine, I get the line in parse.cpp:
> driver.addOp(yystack_[0].value);
> 
>  And after running the debug output prints
> $1 = token INC (1.187-188: )
> 
>  but the yytypeid_ in variant coming to addOp is zero. So `as<token>()' is not
>  applicable (segfault) and I can't detect which token it is. Should the token
>  constructor work for such cases or it's designed only for tokens followed by
>  arguments?

Your scanner looks fine.  You grammar however does not: INC and DEC
are valueless, yet you tried to read from them here:

val_op:
        INC {driver.addOp($1);}
   |    DEC {driver.addOp($1);}

Either give a value to them, or simply use the fact that you do know
in which case you are here.  For instance.

val_op:
        INC {driver.addOp('+');}
   |    DEC {driver.addOp('-');}