Hello Akim, Thank you very much for quick response and addressing this already!
By the way, I was also confused when brew started shipping 3.5.91. I was trying to find out if 3.5.91 is stable release or not and came across this <https://fossies.org/linux/bison/NEWS> and this <https://launchpad.net/bison/head/3.5.91>. By looking at the release tarballs here <https://ftp.gnu.org/gnu/bison/>, it's not obvious which one is beta vs which one is stable. Typically when we package new version inside Spack <https://github.com/spack/spack>, we often look at the release tarballs and add new version (even automatically find one <https://spack.readthedocs.io/en/latest/packaging_guide.html#spack-checksum>). I agree it's not good idea but I wouldn't be surprised if such tarballs are perceived as stable releases. If this is beta version, may be tarball name can indicate that? Regards, Pramod On Sun, May 3, 2020 at 8:33 AM Akim Demaille <[email protected]> wrote: > Hi Pramod, > > > Le 2 mai 2020 à 20:39, pramod kumbhar <[email protected]> a > écrit : > > > > 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. > > W00t??? Home brew ships betas??? That sounds to me like a very silly > idea. It's good that it helps us in the present case, but honestly I > think it's a very bad idea. > > > 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>. > > I'm installing this in master. Which, I guess, will appear in brew > with the next beta... > > commit 20725d57d1805078777ac642de3f6641b6e05af7 > Author: Akim Demaille <[email protected]> > Date: Sun May 3 08:17:05 2020 +0200 > > c++: provide backward compatibility on by_type > > To write unit tests for their scanners, some users depended on > symbol_type::token(): > > Lexer lex("12345"); > symbol_type t = lex.nextToken(); > assert(t.token() == token::INTLIT); > assert(t.value.as<int>() == 12345); > > But symbol_type::token() was removed in Bison 3.5 because it relied on > a conversion table. So users had to find other patterns, such as > > assert(t.type_get() == by_type(token::INTLIT).type_get()); > > which relies on several private implementation details. > > As part of transitioning from "token type" to "token kind", and making > this a public and documented interface, "by_type" was renamed > "by_kind" and "type_get()" was renamed as "kind()". The latter had > backward compatibility mechanisms, not the former. > > In Bison 3.6 none of this should be used, but rather > > assert(t.kind() == symbol_kind::S_INTLIT); > > Reported by Pramod Kumbhar. > https://lists.gnu.org/r/bug-bison/2020-05/msg00012.html > > * data/skeletons/c++.m4 (by_type): Make it an alias to by_kind. > > diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4 > index 8bc70fdf..59c94ce0 100644 > --- a/data/skeletons/c++.m4 > +++ b/data/skeletons/c++.m4 > @@ -414,6 +414,9 @@ m4_define([b4_symbol_type_define], > symbol_kind_type kind_; > }; > > + /// Backward compatibility for a private implementation detail. > + typedef by_kind by_type; > + > /// "External" symbols: returned by the scanner. > struct symbol_type : basic_symbol<by_kind> > {]b4_variant_if([[ > >
