Compilation error with gcc

[drussel]

In file included from /blah/stlab/concurrency/system_timer.hpp:36:0,
                 from /blah/stlab/concurrency/executor_base.hpp:15,
                 from /blah/stlab/concurrency/future.hpp:21,
                 from ../lib/Concurrency/futures.h:12,
                 from ../lib/Concurrency/futures.cpp:1:
/home/velo3d/.conan/data/stlab/1.2.0-0/blah/stlab/concurrency/task.hpp: In instantiation of ‘class stlab::v1::task<void()>’:
/blah/stlab/concurrency/system_timer.hpp:182:26:   required from here
/blah/stlab/concurrency/task.hpp:127:30: error: ‘constexpr’ needed for in-class initialization of static data member ‘const stlab::v1::task<void()>::concept stlab::v1::task<void()>::_vtable’ of non-integral type [-fpermissive]
     static constexpr concept _vtable = {dtor,         move_ctor, invoke,
                              ^
/blah/stlab/concurrency/task.hpp: In instantiation of ‘const stlab::v1::task<void()>::concept stlab::v1::task<void()>::_vtable’:
/blah/stlab/concurrency/task.hpp:130:34:   required from here

As I read it, the values used in the _vtable initialization also need to be constexpr.

GCC 5.4 (ubuntu 16). I'm trying to get it out on ubuntu 18

[sean-parent]

This appears to be a gcc bug fixed in gcc 7.1. The work around is to declare _vtable as const instead of constexpr and move the initializer out of line. If you send a pull request that does this only for gcc < 7.1 then I think we could incorporate it.

Here is the code without the conditionals - compiler explorer is failing to shorten the URL!

[FelixPetriconi]

There is a workaround for this as well: Use gcc with the flags -fpermissive -w.
We use it while compiling the tests on Travis. See ./cmake/GNU.cmake

[drussel]

@FelixPetriconi Yes, we added -fpermissive(the -w doesn't seem to be needed, fortunately). Thanks.

I'll look into producing a patch.

[apmccartney]

Currently, this is addressed by setting fpermissive and w as interface flags, i.e., they propagate to linking targets. Linking to stlab allows non-conformant code to compile in the host code base and disables all warnings. That is very rude behavior in a library.

This would be better address by failing to configure on offending compiler+version and issuing a meaningful message.

[FelixPetriconi]

I understand. I was not aware of this.
Currently, I am looking into this.

[apmccartney]

I am in the preocess of preparing a pull request to improve the CMake anyway. I'll include an implementation of my suggestion. I expect to file it before the weekend.

…

On Wed, Aug 8, 2018 at 1:32 PM Felix Petriconi ***@***.***> wrote: I understand. I was not aware of this. Currently, I am looking into this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#154 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADiSnHhrpqYldwy3cx3Q2MRP-PMIgTaDks5uOzzngaJpZM4UuSn-> .

[FelixPetriconi]

I have the fix done yesterday evening. I just merged it into the develop.

[BMWestrich]

Hi Felix,

do you have any plans on when the next release with this fix will be published? I am working on a fairly large project where we'd like to consume this. Without it we'd be forced to reimplement the work-around as a separate patch only to throw it out after upgrading to the new version.

Thanks,
Benjamin

[FelixPetriconi]

We have another bug #188 in the channels, which I would like to be part of the next release.
I submitted a patch for this bug, which let all tests pass. But before I merge this, I wanted that Sean takes a look into it so be sure that I don't miss an important point. Unfortunately, Sean is currently traveling, so it may take some days for his review. If this takes too long, I will do a release latest on Thursday. I hope that is not too late for you?

[BMWestrich]

No Thursday would be absolutely fine for us.

Thanks!

[FelixPetriconi]

Fixed in 1.3.3