help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible to declare move constructor of basic_symbol as noexcept?


From: Christian Schoenebeck
Subject: Re: Possible to declare move constructor of basic_symbol as noexcept?
Date: Tue, 19 Jan 2021 13:36:19 +0100

On Dienstag, 19. Januar 2021 06:54:48 CET Akim Demaille wrote:
> Adrian,
> 
> See below for my stab at this issue.  Unfortunately it seems to hit
> 
> a problem in GCC10, as the CI features several failures as follows:
> > In file included from ../examples/c++/calc++/driver.hh:24,
> > 
> >                  from ../examples/c++/calc++/driver.cc:20:
> > ./examples/c++/calc++/parser.hh: In instantiation of
> > 'yy::parser::basic_symbol<Base>::basic_symbol(typename Base::kind_type,
> > int&&, yy::parser::location_type&&) [with Base = yy::parser::by_kind;
> > typename Base::kind_type = yy::parser::token::token_kind_type;
> > yy::parser::location_type = yy::location]':
> > ./examples/c++/calc++/parser.hh:742:68:   required from here
> > ./examples/c++/calc++/parser.hh:583:7: internal compiler error:
> > Segmentation fault> 
> >   583 |       basic_symbol (typename Base::kind_type t, int&& v,
> >   location_type&& l)>   
> >       |       ^~~~~~~~~~~~
> > 
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <file:///usr/share/doc/gcc-10/README.Bugs> for instructions.
> 
> I'm not super happy to have to play tricks with compiler macros
> to be able to know if I can trust the compiler :(  If you see
> something wrong in my approach, if you see a nice way to address
> this portability issue, please state it.
> 
> The logs of the CI for this commit are here:
> 
> https://travis-ci.org/github/akimd/bison/builds/755133452
> 
> Cheers!
> 
> commit a7d1aa221efad101d82817345361647fd02a215c
> Author: Akim Demaille <akim.demaille@gmail.com>
> Date:   Mon Jan 18 08:03:44 2021 +0100
> 
>     c++: use YY_NOEXCEPT on the constructor when possible
> 
>     Suggested by Adrian <withoutpointk@gmail.com>.
>     https://lists.gnu.org/r/help-bison/2021-01/msg00008.html
> 
>     * data/skeletons/variant.hh (b4_is_nothrow_move_constructible): New.
>     * data/skeletons/c++.m4: Use it to qualify the basic_symbol ctor.
> 
> diff --git a/data/skeletons/c++.m4 b/data/skeletons/c++.m4
> index cfd4e6ed7..3496450e2 100644
> --- a/data/skeletons/c++.m4
> +++ b/data/skeletons/c++.m4
> @@ -309,7 +309,9 @@ m4_define([b4_symbol_type_define],
> 
>  #if 201103L <= YY_CPLUSPLUS
>        /// Move constructor.
> -      basic_symbol (basic_symbol&& that)
> +      basic_symbol (basic_symbol&& that)]b4_variant_if([
> +        YY_NOEXCEPT (]b4_type_foreach([b4_is_nothrow_move_constructible],
> [[ +                     && ]])[)])[
> 
>          : Base (std::move (that))
> 
>          , value (]b4_variant_if([], [std::move

AFAICS you are conditionally inserting the C++ 'noexcept' qualifier to class 
"basic_symbol"'s constructor (by using C++ type trait 
std::is_nowthrow_move_constructible()), and at the same time you are still 
always using std::move() below though.

Despite the compiler crash, which shouldn't happen of course, that should be 
either noexcept & std::move() otherwise no std::move() at all, at least with 
recent compilers. Not sure what your intention was to leave std::move() 
unconditionally there, I guess for pre-C++11 compilers?

Best regards,
Christian Schoenebeck





reply via email to

[Prev in Thread] Current Thread [Next in Thread]