Re: symbol_type::token () removed?

Hello All,

I haven't looked at what is changed with 3.5.91 but our CI
<https://travis-ci.org/github/BlueBrain/nmodl/jobs/682367580> started
failing with following errors:

[ 27%] Building CXX object
src/lexer/CMakeFiles/lexer_obj.dir/__/parser/diffeq_context.cpp.o
1321/Users/travis/build/BlueBrain/nmodl/src/parser/diffeq_context.cpp:81:41:
error: no member named 'by_type' in 'nmodl::parser::DiffeqParser'
1322        if (token_type ==
DiffeqParser::by_type(DiffeqParser::token::END).type_get()) {
1323

This is after homebrew started shipping <goog_590446785>bison-3.5.91
<https://github.com/Homebrew/homebrew-core/blob/master/Formula/bison.rb>
since yesterday.

I will take a look at the details tomorrow. Here was the previous thread
<https://lists.gnu.org/archive/html/bug-bison/2020-03/msg00015.html>.

Regards,
Pramod

On Tue, Mar 17, 2020 at 6:11 PM Akim Demaille <[email protected]> wrote:

> Hi guys,
>
> You have all been hit by the removal of symbol_type::token (), and I'm not
> sure yet what would be the best option for the future.
>
> We can introduce a %define variable that generates it (and its table) on
> user's request.  But it's going to waste space, unless you use
> api.token.raw.
>
> For a number of reasons, I think it would make sense to expose the
> internal symbol numbers, so
>
> %token FOO 123
>
> would be defined twice: once a TOK_FOO = 123 (the "external token
> number"), and YY_SYMBOL_FOO = 1 (the "internal symbol number").  (In C++ we
> can used something better looking).
>
> Would that be a good solution for you all?  You would no longer need to
> convert from one number type to the other.
>
> Cheers!