Fail to compile on gcc 7.1.1

[Strasser-Pablo]

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.

[Strasser-Pablo]

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]

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]

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]

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]

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]

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).