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 <a...@lrde.epita.fr> 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!