Compilation problem on GCC 14.1 (Linux)

[iwasz]

Hey after upgrade to GCC 14.1 I get:

/usr/include/c++/14.1.1/type_traits:1204:52: error: non-constant condition for static assertion

If I change (remove stuff after noexcept) in build/_deps/daw_utf_range-src/include/daw/utf8/unchecked.h:

constexpr octet_iterator base( ) const
		noexcept( std::is_nothrow_copy_constructible<octet_iterator>::value ) {
	return it;
}

to:

constexpr octet_iterator base( ) const
		noexcept {
	return it;
}

then everything gets back to normal. Dunno if that's something on my side or on library's - any ideas? Thanks!

[beached]

I see that with gcc 14.1 in the tests. I doubt it is your code. Looking into it

[beached]

Interesting that with the same libstdc++, gcc 14.1 fails this and clang does not. But the type definitely is complete as it is checking std::is_nothrow_copy_constructible<char const *>::value

[iwasz]

I found this : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100381 does it help?

…

On Mon, Jul 1, 2024 at 7:16 AM Darrell Wright ***@***.***> wrote: Interesting that with the same libstdc++, gcc 14.1 fails this and clang does not. But the type definitely is complete as it is checking std::is_nothrow_copy_constructible<char const *>::value — Reply to this email directly, view it on GitHub <#429 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4N35BWXI4XO5RHZDDXSDZKDQ3XAVCNFSM6AAAAABKD74RH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJZGI2TIOBTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[beached]

Same thing catching, but how can a char const * be an incomplete type right? Plus the code has compiled in constant expressions that would have checked that anyways. I get they are trying to prevent ODR here. Still looking to see if the error is wrong on the type and I have invalid code though

[beached]

I have a fix in the utf-range repo that will work around this. I am thinking it is a compiler issue but could not replicate a small example. changing the std::is_nothrow_copy_constructible<T>::value to std::is_nothrow_copy_constructibe_v<T> works around the issue.

[beached]

This should be fixed now

[iwasz]

Thanks!