Open checkraisefold opened 8 months ago
I have this issue too. For what it's worth, replacing upvalue_this_member_variable::call()
's noexcept(std::is_nothrow_copy_assignable_v<T>)
specification by either noexcept(true)
, noexcept(false)
or even removing it entirely seems to "fix" it for some reason. I don't really understand that behavior right now, but maybe that can help a bit.
Same issue here while building MAME, latest MSYS2 has just deployed LLVM 18.1 components.
Possibly related to the following Clang bugfix "Clang will correctly evaluate noexcept expression for template functions of template classes." - see https://prereleases.llvm.org/18.1.0/rc3/tools/clang/docs/ReleaseNotes.html
The workaround from Razakhel above resolves compilation but the binary is non-working.
Binary is working now with compilation workaround, was unrelated error my part.
I think this is a bug in clang. The noexcept
specification isn’t part of the function type. You can see it accepts it without a noexcept
specification at all or with a fixed noexcept
(which will obviously cause issues if the assignment can throw an exception). Is it possible to create a minimal case exposing this to report upstream?
OK, it’s actually pretty easy to reproduce – this builds with clang 17 but not with clang 18 as C++17:
template <typename T>
struct class_tmpl {
template <bool B> static void call_e() { }
template <bool B> static void call_ne() noexcept { }
template <bool B> static void call() noexcept(sizeof(T) > 1) { }
};
int main(int argc, char *argv[])
{
using function_ptr = void (*)();
function_ptr f1 = &class_tmpl<int>::call_e<false>;
function_ptr f2 = &class_tmpl<int>::call_ne<false>;
function_ptr f3 = &class_tmpl<int>::call<false>;
return 0;
}
Results:
test.cpp:13:24: error: address of overloaded function 'call' does not match required type 'void ()'
13 | function_ptr f3 = &class_tmpl<int>::call<false>;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test.cpp:5:35: note: candidate template ignored: substitution failure [with B = false]
5 | template <bool B> static void call() noexcept(sizeof(T) > 1) { }
| ^
1 error generated.
Reported as llvm/llvm-project#91362
Fixed in llvm main branch by llvm/llvm-project#90760. I don't know when this will make it into a clang release.
Cool, I'll close this as soon as it's in a Clang release and tested
You can use this workaround in the mean time:
diff --git a/3rdparty/sol2/sol/sol.hpp b/3rdparty/sol2/sol/sol.hpp index 8b0b7d36ea4ef..1a9375d996d2f 100644
--- a/3rdparty/sol2/sol/sol.hpp
+++ b/3rdparty/sol2/sol/sol.hpp
@@ -19416,7 +19416,13 @@ namespace sol { namespace function_detail {
}
template <bool is_yielding, bool no_trampoline>
- static int call(lua_State* L) noexcept(std::is_nothrow_copy_assignable_v<T>) {
+ static int call(lua_State* L)
+#if SOL_IS_ON(SOL_COMPILER_CLANG)
+ // apparent regression in clang 18 - llvm/llvm-project#91362
+#else
+ noexcept(std::is_nothrow_copy_assignable_v<T>)
+#endif
+ {
int nr;
if constexpr (no_trampoline) {
nr = real_call(L);
@@ -19456,7 +19462,13 @@ namespace sol { namespace function_detail {
}
template <bool is_yielding, bool no_trampoline>
- static int call(lua_State* L) noexcept(std::is_nothrow_copy_assignable_v<T>) {
+ static int call(lua_State* L)
+#if SOL_IS_ON(SOL_COMPILER_CLANG)
+ // apparent regression in clang 18 - llvm/llvm-project#91362
+#else
+ noexcept(std::is_nothrow_copy_assignable_v<T>)
+#endif
+ {
int nr;
if constexpr (no_trampoline) {
nr = real_call(L);
That's on the single-header version, but you should be able to work out how to apply it to the source headers.
Hey @ThePhD What do you think if I make a PR to include workaround from this comment above to main branch? It seems clang-16/clang-17/clang-18 all have this issue.
I find it ironic that a popular library by someone on the committee is not considered worthy enough of llvm devs to back-port fixes for lol.
I have this issue too. For what it's worth, replacing
upvalue_this_member_variable::call()
'snoexcept(std::is_nothrow_copy_assignable_v<T>)
specification by eithernoexcept(true)
,noexcept(false)
or even removing it entirely seems to "fix" it for some reason. I don't really understand that behavior right now, but maybe that can help a bit.
Attempted this fix, did not work for me
On the latest major release (candidate) of Clang, sol2 flat out doesn't compile with a fatal error and spits out a bunch of warnings. https://github.com/jpxs-intl/RosaServer/actions/runs/7929791195/job/21650728959 for the run logs, or here: