[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: symbol_type::token () removed?
From: |
pramod kumbhar |
Subject: |
Re: symbol_type::token () removed? |
Date: |
Sun, 3 May 2020 09:10:08 +0200 |
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 <address@hidden> wrote:
> Hi Pramod,
>
> > Le 2 mai 2020 à 20:39, pramod kumbhar <address@hidden> 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 <address@hidden>
> 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([[
>
>
- Re: symbol_type::token () removed?, pramod kumbhar, 2020/05/02
- Re: symbol_type::token () removed?, Akim Demaille, 2020/05/03
- Re: symbol_type::token () removed?,
pramod kumbhar <=
- Re: symbol_type::token () removed?, Akim Demaille, 2020/05/03
- Re: symbol_type::token () removed?, pramod kumbhar, 2020/05/03
- Re: symbol_type::token () removed?, Akim Demaille, 2020/05/03
- Re: symbol_type::token () removed?, pramod kumbhar, 2020/05/03
- Re: symbol_type::token () removed?, Akim Demaille, 2020/05/03
Re: symbol_type::token () removed?, uxio prego, 2020/05/04