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

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Dec 3 17:15:04 PST 2020


rjmccall added a comment.

In D92361#2432578 <https://reviews.llvm.org/D92361#2432578>, @ahatanak wrote:

> It seems like you are discussing the case where a class/struct annotated with `trivial_abi` contains a member that isn't destructively movable. In that case, clang correctly diagnoses it today. For example, if you remove the attribute from `S2` in the above example and add it to `S3` instead, it warns that `trivial_abi` cannot be applied to `S3` because `S2` is a non-trivial class type.
>
> What I wasn't sure was whether `S1` (which isn't annotated with `trivial_abi` in the original code I posted) should be treated as a destructively movable type despite having all its copy/move constructors deleted when its only member (`s0`) is destructively movable.
>
> Based on the discussion we had a few years ago (http://lists.llvm.org/pipermail/cfe-dev/2017-November/055966.html), I think the answer is yes, but I just wanted to confirm.

Hmm.  My first instinct is to say that a type that "adds new information" about its special members — i.e. that explicitly declares its destructor or copy/move constructors for some reason other than to immediately explicitly default them — should always be treated conservatively in the absence of a `trivial_abi` attribute.  So a type that explicitly deletes all its copy/move constructors should never be treated as destructively movable without the attribute.  A type with implicitly-deleted copy/move constructors due solely to subobjects that are still destructively movable should still be destructively movable, I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92361



More information about the cfe-commits mailing list