Re: RFC: creating a bison-announce list
Hi Simon, > On 27 Dec 2018, at 04:29, Simon Richter wrote: > > [...] > > [...] Setting up a CI > system that pulls "experimental" Bison into a chroot and test-compiles a > project there is doable with medium effort, but we'd have to actively > convince people to do that, and package maintainers would have to be on > board. Just in case you missed it, Akim set up some Travis pipelines [1]. > [...] Maybe simply learning from past mistakes and tailoring some post build scripts emulating actual corner use cases does the trick. Thumb up for an announce list, only if you can handle it with ease. In some previous life I found announce lists a helpful facility in order to track changes of depended free and open source software. Instead of rushing versions, establish release candidates. This won't help too much as per stated in the thread, but won't do harm and may catch some bug who knows. If you worry about tag hell, you don't really need annotated tags for release candidates, or even to have them as long lived tags. Don't be sorry for your users about iterating quickly the bugfix part of the version number. You are who bear the actual costs, by acting promptly when breaking something. Thank you. Regards, [1]: https://travis-ci.com/akimd/bison/builds/95932137 ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Using api.token.constructor for tokens without arguments.
Hi!
> Le 25 août 2015 à 14:20, Slava Barinov 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()' 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('-');}
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
