[Clang] `__is_trivially_copyable` returns wrong result for classes with a `const` member.

[philnik777]

struct S {
  int offset_;
};

struct pair
{
  int first;
  const S second;

  pair& operator=(const pair&) = default;
  pair& operator=(pair&&) = default;
};

static_assert(__is_trivially_copyable(pair));

pair should be trivially copyable, but isn't reported as such currently. Note that removing the defaulted assignment operators and adding pair(const pair&) = default; results in Clang reporting pair as trvially copable correctly.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nikolas Klauser (philnik777)

```c++ struct S { int offset_; }; struct pair { int first; const S second; pair& operator=(const pair&) = default; pair& operator=(pair&&) = default; }; static_assert(__is_trivially_copyable(pair)); ``` `pair` should be trivially copyable, but isn't reported as such currently. Note that removing the defaulted assignment operators and adding `pair(const pair&) = default;` results in Clang reporting `pair` as trvially copable correctly.

[Endilll]

GCC and EDG agree that the code is valid: https://godbolt.org/z/ch5ndY4ra

[llvmbot]

@llvm/issue-subscribers-c-1

Author: Nikolas Klauser (philnik777)

```c++ struct S { int offset_; }; struct pair { int first; const S second; pair& operator=(const pair&) = default; pair& operator=(pair&&) = default; }; static_assert(__is_trivially_copyable(pair)); ``` `pair` should be trivially copyable, but isn't reported as such currently. Note that removing the defaulted assignment operators and adding `pair(const pair&) = default;` results in Clang reporting `pair` as trvially copable correctly.

[zygoloid]

Should S be trivially copyable? It looks to me like:

• Its copy and move assignments are deleted because of the const member
• Its copy constructor is deleted because of the user-declared move assignment
• Its move constructor is not declared because of the user-declared assignment operators ... so it looks to me like it's not copyable at all.

[AaronBallman]

References for what @zygoloid posted above:

• Copy and move assign deleted due to const member: https://eel.is/c++draft/class.copy.assign#7.1
• Deleted copy constructor: https://eel.is/c++draft/class.copy.ctor#6.sentence-2
• No move constructor declared: https://eel.is/c++draft/class.copy.ctor#8

And the library defers to the language in this case: https://eel.is/c++draft/type.traits#tab:meta.unary.prop-row-5-column-2-sentence-1, https://eel.is/c++draft/basic.types.general#9.sentence-2, https://eel.is/c++draft/class.prop#1

[Endilll]

So http://eel.is/c++draft/class.copy.ctor#11 was a red herring

[AaronBallman]

Not a red herring, I think it's more that it doesn't apply because the copy constructor is deleted and there's no move constructor.

[frederick-vs-ja]

This seems related to CWG1734.

[philnik777]

If that's the case, shouldn't

struct S {
  int offset_;
};

struct pair
{
  int first = {};
  const S second = {};

  pair() = default;
  pair(const pair&) = default;
  pair(pair&&) = default;
  pair& operator=(const pair&) = default;
  pair& operator=(pair&&) = default;
};

be considered trivially copyable? I can definitely copy construct it, but it's not trivially copyable according to Clang: https://godbolt.org/z/qn4K1G6sY

[AaronBallman]

We have other issues regarding calculating what is trivially copyable, e.g., https://github.com/llvm/llvm-project/issues/38398