Trivial relocatability/replaceability of class with user-provided defaulted destructor

[jakubjelinek]

I've tried to turn the https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#simple-worked-examples examples into a testcase:
https://godbolt.org/z/h4We6c8KM
Trying this with clang and gcc (in that case using _is* traits rather than the _builtin_is_cpp* or _builtin_is* ones), I get similar results (tons of failed assertions, will need to go through that, wonder if it is from some earlier version of the paper not updated afterwards or what) between the two compilers, except for the

struct I { ~I (); };
I::~I () = default;

static_assert (!std::is_trivially_copyable_v <I>, "");
static_assert (!std::is_trivially_relocatable_v <I>, "");
static_assert (!std::is_replaceable_v <I>, "");

testcase in there, where it passes with GCC but the last 2 assertions fail with clang trunk.
My reading of the standard is that I has user-provided destructor and so according to
https://eel.is/c++draft/class.prop#2.3
shouldn't be default-movable and while it is eligible for trivial relocation and eligible for replacement, because it doesn't have the conditional keywords and is not a union, it should be neither trivially relocatable nor replaceable.

BTW, as the appendix says,

struct C {}; struct C replaceable_if_eligible {};

should be valid in C++11 through C++23, but clang trunk rejects that.

@cor3ntin

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Jakub Jelínek (jakubjelinek)

I've tried to turn the https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#simple-worked-examples examples into a testcase: https://godbolt.org/z/h4We6c8KM Trying this with clang and gcc (in that case using __is_* traits rather than the __builtin_is_cpp_* or __builtin_is_* ones), I get similar results (tons of failed assertions, will need to go through that, wonder if it is from some earlier version of the paper not updated afterwards or what) between the two compilers, except for the ```c struct I { ~I (); }; I::~I () = default;

static_assert (!std::is_trivially_copyable_v <I>, "");
static_assert (!std::is_trivially_relocatable_v <I>, "");
static_assert (!std::is_replaceable_v <I>, "");

testcase in there, where it passes with GCC but the last 2 assertions fail with clang trunk.
My reading of the standard is that I has user-provided destructor and so according to
https://eel.is/c++draft/class.prop#<!-- -->2.3
shouldn't be default-movable and while it is eligible for trivial relocation and eligible for replacement, because it doesn't have the conditional keywords and is not a union, it should be neither trivially relocatable nor replaceable.

BTW, as the appendix says,
```c
struct C {}; struct C replaceable_if_eligible {};

should be valid in C++11 through C++23, but clang trunk rejects that.

@cor3ntin

[jakubjelinek]

One more thing, why __builtin_is_cpp_trivially_relocatable rather than just __builtin_is_trivially_relocatable ?

[cor3ntin]

Thanks ! I opened a PR.

Trying this with clang and gcc (in that case using _is* traits rather than the _builtin_is_cpp* or _builtin_is* ones),

We left __is_trivially_relocatable untouched from what clang did in previous versions and deprecated it. That type trait was mostly built around [[trivial_abi]] and gives different results depending on calling conventions (in addition to giving different results for polymorphic types, not considering assignment operators, etc)

BTW, as the appendix says,
struct C {}; struct C replaceable_if_eligible {};
should be valid in C++11 through C++23, but clang trunk rejects that.

Clang decided to support trivial relocation in older language modes. While this is not strictly conforming, it's extremely unlikely that these identifiers would be present in existing code.

[cor3ntin]

One more thing, why __builtin_is_cpp_trivially_relocatable rather than just __builtin_is_trivially_relocatable ?

To avoid confusion with __is_trivially_relocatable

[jakubjelinek]

One more thing, why __builtin_is_cpp_trivially_relocatable rather than just __builtin_is_trivially_relocatable ?

To avoid confusion with __is_trivially_relocatable

I think more confusing is __builtin_is_replaceable vs. __builtin_is_cpp_trivially_relocatable.
We are currently considering using __builtin_is_replaceable vs. __builtin_is_trivially_relocatable in GCC for the 2 traits (and __builtin_is_nothrow_relocatable as well.

Clang decided to support trivial relocation in older language modes. While this is not strictly conforming, it's extremely unlikely that these identifiers would be present in existing code.

We are leaning towards only supporting __trivially_relocatable_if_eligible and __replaceable_if_eligible conditional keywords
before C++26 (with no pedantic diagnostics, like e.g. __final). Though seems clang++ doesn't even support __final.

[cor3ntin]

I think more confusing is __builtin_is_replaceable vs. __builtin_is_cpp_trivially_relocatable.
We are currently considering using __builtin_is_replaceable vs. __builtin_is_trivially_relocatable in GCC for the 2 traits (and __builtin_is_nothrow_relocatable as well.

I'm not opposed to changing the name, we should try to avoid using different names in different implementations, though.

is_nothrow_relocatable_v

Not sure we need a built-in for that - at least I did not plan to add one in Clang.