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

Fail to compile on gcc 7.1.1 #414

Closed
Strasser-Pablo opened this issue May 30, 2017 · 6 comments
Closed

Fail to compile on gcc 7.1.1 #414

Strasser-Pablo opened this issue May 30, 2017 · 6 comments
Assignees
Labels
Bug.Well Shit Here we go again... Speed.Compilation Oh boy I sure do love these IDEs chugging for an eternity.
Milestone

Comments

@Strasser-Pablo
Copy link

Strasser-Pablo commented May 30, 2017

Hi,
I just updated my gcc version and am unable to compile the sol2 code, I guess it is because of change introduced in c++17.
Here is an excerpt of the error:

[1/48] compiling test_storage.cpp to obj/test_storage.o
FAILED: obj/test_storage.o
g++ -MMD -MF obj/test_storage.o.d -c -Wall -Wextra -Wpedantic -pedantic -pedantic-errors -std=c++14 -ftemplate-depth=1024 -DNDEBUG -O3 -I"." -I"./include" -I"/usr/include/lua5.3" -I"/usr/local/include/lua5.3" -isystem"Catch/include" -Werror test_storage.cpp -o obj/test_storage.o
In file included from ./sol/stack.hpp:27:0,
from ./sol/object.hpp:26,
from ./sol/proxy.hpp:26,
from ./sol/table_core.hpp:25,
from ./sol/table.hpp:25,
from ./sol/state_view.hpp:26,
from ./sol/state.hpp:25,
from ./sol.hpp:45,
from test_storage.cpp:4:
./sol/stack_check.hpp: In instantiation of ‘static bool sol::stack::checker<T, (sol::type)6, C>::check(lua_State*, int, Handler&&, sol::stack::record&) [with Handler = int (&)(lua_State*, int, sol::type, sol::type) noexcept; T = sol::coroutine; C = void; lua_State = lua_State]’:
./sol/stack_core.hpp:233:69: required from ‘bool sol::stack::check(lua_State*, int, Handler&&, sol::stack::record&) [with T = sol::coroutine; Handler = int (&)(lua_State*, int, sol::type, sol::type) noexcept; lua_State = lua_State]’
./sol/stack_core.hpp:239:19: required from ‘bool sol::stack::check(lua_State*, int, Handler&&) [with T = sol::coroutine; Handler = int (&)(lua_State*, int, sol::type, sol::type); lua_State = lua_State]’
./sol/coroutine.hpp:87:48: required from here
./sol/stack_check.hpp:234:16: error: mangled name for ‘static bool sol::stack::checker<T, (sol::type)6, C>::check(lua_State*, int, Handler&&, sol::stack::record&) [with Handler = int (&)(lua_State*, int, sol::type, sol::type) noexcept; T = sol::coroutine; C = void; lua_State = lua_State]’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
static bool check(lua_State* L, int index, Handler&& handler, record& tracking) {
^~~~~
./sol/stack_check.hpp:246:24: error: mangled name for ‘callkey’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
static const auto& callkey = to_string(meta_function::call);`

Removing -wall , pedantic from the build.ninja file allows to build more:
test_functions.cpp:243:91: error: ambiguous overload for ‘operator=’ (operand types are ‘std::pair<int, int>’ and ‘sol::function_result’)
cd = lua_bark(std::make_pair(lua["nested"]["variables"]["no"]["problem"], cpp_variable_y));
^
In file included from /usr/include/c++/7.1.1/bits/stl_algobase.h:64:0,
from /usr/include/c++/7.1.1/bits/char_traits.h:39,
from /usr/include/c++/7.1.1/ios:40,
from /usr/include/c++/7.1.1/istream:38,
from /usr/include/c++/7.1.1/sstream:38,
from Catch/include/internal/catch_common.h:24,
from Catch/include/internal/catch_notimplemented_exception.h:11,
from Catch/include/catch.hpp:31,
from test_functions.cpp:3:
/usr/include/c++/7.1.1/bits/stl_pair.h:367:7: note: candidate: std::pair<_T1, _T2>& std::pair<_T1, _T2>::operator=(typename std::conditional<std::_and<std::is_copy_assignable<_Tp>, std::is_copy_assignable<_T2> >::value, const std::pair<_T1, _T2>&, const std::__nonesuch_no_braces&>::type) [with _T1 = int; _T2 = int; typename std::conditional<std::_and<std::is_copy_assignable<_Tp>, std::is_copy_assignable<_T2> >::value, const std::pair<_T1, _T2>&, const std::__nonesuch_no_braces&>::type = const std::pair<int, int>&]
operator=(typename conditional<
^~~~~~~~
/usr/include/c++/7.1.1/bits/stl_pair.h:378:7: note: candidate: std::pair<_T1, _T2>& std::pair<_T1, _T2>::operator=(typename std::conditional<std::_not<std::_and<std::is_copy_assignable<_Tp>, std::is_copy_assignable<_T2> > >::value, const std::pair<_T1, _T2>&, const std::__nonesuch_no_braces&>::type) [with _T1 = int; _T2 = int; typename std::conditional<std::_not<std::_and<std::is_copy_assignable<_Tp>, std::is_copy_assignable<_T2> > >::value, const std::pair<_T1, _T2>&, const std::__nonesuch_no_braces&>::type = const std::__nonesuch_no_braces&]
operator=(typename conditional<
^~~~~~~~
/usr/include/c++/7.1.1/bits/stl_pair.h:384:7: note: candidate: std::pair<_T1, _T2>& std::pair<_T1, _T2>::operator=(typename std::conditional<std::_and<std::is_move_assignable<_Tp>, std::is_move_assignable<_T2> >::value, std::pair<_T1, _T2>&&, std::__nonesuch_no_braces&&>::type) [with _T1 = int; _T2 = int; typename std::conditional<std::_and<std::is_move_assignable<_Tp>, std::is_move_assignable<_T2> >::value, std::pair<_T1, _T2>&&, std::__nonesuch_no_braces&&>::type = std::pair<int, int>&&]
operator=(typename conditional<

If you need help to test, I'm at your disposale.

@ThePhD ThePhD self-assigned this May 31, 2017
@ThePhD ThePhD added Bug.Well Shit Here we go again... Speed.Compilation Oh boy I sure do love these IDEs chugging for an eternity. labels May 31, 2017
@ThePhD ThePhD added this to the BugsDamnit milestone May 31, 2017
@Strasser-Pablo
Copy link
Author

I managed to convert my library using sol2 without change.
The only thing I needed to change was that I cannot recover the string result of a lua function using assignement to std::string because of operator overload conflict of the assign function.
Using a static_cast to string work.

@ThePhD
Copy link
Owner

ThePhD commented May 31, 2017

There were new constructors for pair, tuple, and string that were added. I need to sift through the new standard and figure out how to avoid the ambiguities on conversion again, so that will take me a little while to do...

@ThePhD
Copy link
Owner

ThePhD commented Jun 3, 2017

This is more nightmarish than I thought. GCC added a chockful of new warnings about noexcept specifications on function pointers too, and I honestly do NOT care about them in the slightest...

Why does gcc have to be so noisy with every new release?

@Strasser-Pablo
Copy link
Author

Thanks for working on making sol2 work on a very new version of a compiler.
Personally I can live with warning especially in the start of the live of a new release of a compiler.
I'm more concerned about hard error.
Personally I always found gcc to be a too verbose compiler even if they made some progress on that.
I didn't find it in the gcc documentation but maybe its possible to only turn the new warning off.

@ThePhD
Copy link
Owner

ThePhD commented Jun 7, 2017

I've turned off the new warnings wherever I could, but since this is a header-only library some template instantiations escape my scope.

There's nothing I can do when someone does

std::string s;
s = some_sol_function();

In VC++ this works, but in clang++/g++ they've broken the copy operators with the way they perform SFINAE and the way overloads are ranked, resulting in an ambiguous operation. The only cross-platform way to do it is to use the some_sol_function.call<std::string>(); or some_sol_function.call<std::pair<int, int>>(); or to use a static_cast, as you observed. There's unfortunately absolutely nothing I can do about g++ being broken about this.

@ThePhD
Copy link
Owner

ThePhD commented Jun 7, 2017

Note that this only affects operator= (assignment). For constructors, it works just fine, so operator= is the only busted thing. For once, VC++ does what I think is the right thing in the way they rank overloads, but I have no idea if it's "standards compliant" and honestly I'm too tired to read the standard and go file a bug against VC++ or clang++/g++ (especially the latter: my bug report from over a year ago is still sitting unanswered and probably will be for the rest of my existence).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug.Well Shit Here we go again... Speed.Compilation Oh boy I sure do love these IDEs chugging for an eternity.
Projects
None yet
Development

No branches or pull requests

2 participants