Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't build on Fedora 30 #112

Closed
Mathok opened this issue May 14, 2019 · 3 comments
Closed

Can't build on Fedora 30 #112

Mathok opened this issue May 14, 2019 · 3 comments

Comments

@Mathok
Copy link

Mathok commented May 14, 2019

error.cc:35:54: error: non-local lambda expression cannot have a capture-default
35 | function<void(string s)> current_catch_explainer = [&](string s) {
| ^
make[1]: *** [Makefile:47: error.o] Error 1

the bug happens with 0.6.1 and git master and there is also a gentoo bugtracker entry for this https://bugs.gentoo.org/685714

@automorphism88
Copy link

Does Fedora include GCC 9? Because on Gentoo, that error occurs with GCC 9.1, but it builds fine with GCC 8.3. I haven't tried clang or any other GCC versions.

@kakra
Copy link
Contributor

kakra commented Jun 10, 2019

This affects both the 0.6 branch and the master branch.

@Zygo Should we fix and backport to 0.6, or move forward to an 0.7 version?

@Zygo
Copy link
Owner

Zygo commented Jun 13, 2019

That lambda doesn't need a capture, because there's nothing in scope that it could capture that the function body doesn't already have access to. Apparently that's an error in C++11, but no version of GCC before 9 notices this.

@kakra We should probably go forward to 0.7 because it's long overdue.

I had wanted to do a bunch of stuff in 0.7, but then other plans took priority, and I also wandered away from bees for a bit to fight kernel bugs for a while. So I think I'm just going to push out a few small fixes for 0.7 soon, and try to get the bigger stuff done in 0.8.

@Zygo Zygo closed this as completed in 228747a Jun 13, 2019
kakra pushed a commit to kakra/bees that referenced this issue Oct 29, 2019
We got away with this because GCC 4.8 (and apparently every GCC prior
to 9) didn't notice or care, and because there is nothing referenced
inside the lambda function body that isn't accessible from any other
kind of function body (i.e. the capture wasn't needed at all).

GCC 9 now enforces what the C++ standard said all along:  there is
no need to allow capture-default in this case, so it is not.

Fix by removing the offending capture-default.

Fixes: Zygo#112
Signed-off-by: Zygo Blaxell <bees@furryterror.org>
kakra pushed a commit to kakra/bees that referenced this issue Oct 29, 2019
We got away with this because GCC 4.8 (and apparently every GCC prior
to 9) didn't notice or care, and because there is nothing referenced
inside the lambda function body that isn't accessible from any other
kind of function body (i.e. the capture wasn't needed at all).

GCC 9 now enforces what the C++ standard said all along:  there is
no need to allow capture-default in this case, so it is not.

Fix by removing the offending capture-default.

Fixes: Zygo#112
Signed-off-by: Zygo Blaxell <bees@furryterror.org>
kakra pushed a commit to kakra/bees that referenced this issue Nov 28, 2019
We got away with this because GCC 4.8 (and apparently every GCC prior
to 9) didn't notice or care, and because there is nothing referenced
inside the lambda function body that isn't accessible from any other
kind of function body (i.e. the capture wasn't needed at all).

GCC 9 now enforces what the C++ standard said all along:  there is
no need to allow capture-default in this case, so it is not.

Fix by removing the offending capture-default.

Fixes: Zygo#112
Signed-off-by: Zygo Blaxell <bees@furryterror.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants