[PATCH] D92361: [trivial-abi] Support types without a copy or move constructor.

Tue Dec 1 21:27:31 PST 2020

zoecarver added a comment.

> If it is not possible to copy or move the type at all, it is not possible to copy or move it trivially.

This was a bit confusing to me because I think this changed between C++14 and 17. In C++14, a class was trivially copyable if it had no non-trivial copy/move constructors. But now the standard requires at least one non-trivial move/copy constructor. It looks like <https://godbolt.org/z/47W7qK> the type traits maybe haven't caught up.

> So S0 may representationally depend on its address, and we should ignore/diagnose trivial_abi on aggregates containing an S0.

I guess the question is, does a type with all copy/move constructors deleted //and the trivial_abi attribute// depend on its address? And the whole point of this patch is to make that answer, "no." But, a type //without// the attribute, //does// depend on its address. And therefore a type holding `S0` (without the attribute) also depends on its address because it implicitly has no copy/move constructors. I'm not sure I understand why we need to diagnose aggregates containing an `S0` or why the trivial_abi attribute couldn't be applied to those types, though.

> Similarly, if a subobject type has only non-trivial copy/move constructors (but a trivial destructor), we should assume that it representationally depends on its address and prevent aggregates containing it from being passed directly, even if the containing type deletes all its copy/move constructors and uses trivial_abi.

I concur with the first part of this, at least. That is, `S3` should //not// be passed directly because it is non-trivially copyable (because of its member) and does not have the attribute. Similar to above, I don't understand why we couldn't pass it directly if it had the attribute, though.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92361/new/

https://reviews.llvm.org/D92361