P1144 "Trivially relocatable" (0/3): Compiler support for `__is_trivially_relocatable(T)`

[• Quuxplusone]

Summary

Part 0/3 is D50119: it adds __has_extension(__is_trivially_relocatable) to the compiler.
Part 1/3 is D61761: it implements the library traits and algorithms mandated by P1144.
Part 2/3 is D63620: it implements Quality-of-Implementation features to warrant certain std library types as "trivially relocatable."
Part 3/3 is D67524: it implements Quality-of-Implementation features to optimize certain std library functions for better performance on types that have been warranted "trivially relocatable."

This is the compiler half of C++ proposal 1144 "Object relocation in terms of move plus destroy," as seen on https://godbolt.org/g/zUUAVW and https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-relocatable/ .

There are two parts to this compiler support:

• the type trait __is_trivially_relocatable(T), which is similar in spirit to __is_trivially_destructible(T), in that it lets the programmer access information that the compiler itself already knows; and
• the warranting attribute [[clang::trivially_relocatable]], which is similar in spirit to [[clang::trivial_abi]], in that it lets the programmer communicate back to the compiler that a certain user-defined type should be assumed to have this property even though it would not naturally have the property all else being equal.

As proposed in P1144R3, [[clang::trivially_relocatable(some-bool-expr)]] can be used to make a type conditionally trivially relocatable. I used this version of the attribute very heavily in my libc++ patch D63620.

Furthermore, I've implemented @rjmccall's idea for an attribute [[clang::maybe_trivially_relocatable]] that says "My member functions don't interfere with my own trivial relocatability, but my data members' types might." Personally I have not used this version of the attribute, but I am certainly biased. See my C++Now 2019 session ( https://www.youtube.com/watch?v=SGdfPextuAU&t=40m ) for details on the different approaches to conditionally trivial relocatability.

The official home of this branch thus far has been https://github.com/Quuxplusone/clang/tree/trivially-relocatable , but I figure that a Clang review would be a good way to get some more eyeballs on it, plus, if we can get it into Clang trunk then I wouldn't have to keep rebasing it.

[Rakete1111]

• There's a bug in your implementation:

struct X {
  X &operator=(X &&);
};
static_assert(__is_trivially_relocatable(X)); // oops, fires!

X has a move constructor and a destructor, so it is trivially relocatable.

• Please run your code through clang-format.

• Might be useful to add a note explaining why the type isn't trivially relocatable instead of the general "because it is not destructible".

include/clang/Sema/Sema.h

4304

Any reason why this is a free function? Should be a member function of QualType.

lib/AST/DeclCXX.cpp

283

Lingering debug message? :) There are many of them.

For a single expression, drop the braces of the if statement.

lib/Sema/SemaDeclCXX.cpp

6066

This should be a // TODO: .... Is this comment really appropriate? The intended audience isn't compiler writers I think.

6157

This really just checks whether the type has defaulted copy constructor. If there was a move constructor, it would have been handled above. If the copy/move constructor is implicitly deleted, it would have been handled also above. Please simplify this accordingly.

6158

Why do you need to check whether the attribute is present or not? This is supposed to be whether the type is naturally trivially relocatable, so the presence of the attribute is not important.

6656

You don't actually need those three lines. This is already handled in CheckCompletedCXXClass.

test/SemaCXX/trivially-relocatable.cpp

43

Why does this restriction exist? None of the existing attributes have it and I don't see why it would make sense to disallow this.

472

This is the right place for regression tests. Add them to test/Parser/cxx-class.cpp.

[• Quuxplusone]

Address feedback from @Rakete1111. Fix wrong ordering of 'class|struct|...' in the diagnostic. Add union test cases. Correctly drop the attribute whenever it is diagnosed as inapplicable.

include/clang/Basic/DiagnosticSemaKinds.td

2942

Might be useful to add a note explaining why the type isn't trivially relocatable instead of the general "because it is not destructible".

You mean, like, a series of notes pointing at "because its base class B is not destructible... because B's destructor is defined as deleted here"? I agree that might be helpful, but since it only happens when the programmer is messing around with the attribute anyway, I wouldn't want to do anything too innovative or LoC-consuming. I'd cut and paste ~10 lines of code from somewhere else that already does something like that if you point me at it, but otherwise I think it's not worth the number of extra codepaths that would need to be tested.

include/clang/Sema/Sema.h

4304

class QualType is defined in AST/, whereas all the C++-specific TriviallyRelocatable stuff is currently confined to Sema/. My impression was that I should try to preserve that separation, even if it meant being ugly right here. I agree that this is a stupid hack, and would love to get rid of it, but I think I need some guidance as to how much mixing of AST and Sema is permitted.

lib/Sema/SemaDeclCXX.cpp

6066

Similar to the //puts comments, this comment is appropriate for me but not for Clang. :) Will replace with a comment containing the actual proposed wording.

6157

Can you elaborate on this one? I assume you mean that some of lines 6157 through 6171 are superfluous, but I can't figure out which ones or how to simplify it.

6158

I just thought that checking the presence of the attribute would be cheaper than doing these lookups, so I was trying to short-circuit it. However, you are correct for two reasons:

• The check passes 99.99% of the time anyway, so it's *everyone* paying a small cost just so that the 0.01% can be a bit faster. This is a bad tradeoff.
• Skipping the check when the attribute is present is actually incorrect, in the case that the type is not relocatable and the attribute is going to be dropped. (It was not dropped in this revision. It will be dropped in the next revision.) In that case, even with the attribute, we still want to execute this codepath.

6656

Confirmed. Nice!

test/SemaCXX/trivially-relocatable.cpp

43

[[noreturn]] has it, and I am pretty sure that [[trivial_abi]] *ought* to have it, even though it currently doesn't. The intent is to make it harder for people to create ODR violations by declaring a type, using it in some way, and then saying "oh by the way this type was xxxxx all along."

struct S { S(S&&); ~S(); };
std::vector<S> vec;
struct [[trivially_relocatable]] S;  // ha ha, now you have to re-do all of vector's codegen!

Does that make sense as a reason it would be (mildly) beneficial to have this diagnostic?
You could still reasonably object to my assumptions that (A) the diagnostic is worth implementing in Clang and/or (B) the diagnostic is worth mandating in the Standard wording; but FWIW I do think it's very cheap both to implement and to specify.

(I will try to adjust the patch so that after the error is given, we remove the attribute from the class so as to make consistent any subsequent cascading errors. https://godbolt.org/g/nVRiow )

430

There's a bug in your implementation:

struct X {
  X &operator=(X &&);
};
static_assert(__is_trivially_relocatable(X)); // oops, fires!

X has a move constructor and a destructor, so it is trivially relocatable.

Actually, this X does *not* have a move constructor! And its copy constructor is implicitly deleted. So it is not relocatable, let alone trivially relocatable.
https://godbolt.org/g/ZsCqvd

<source>:15:7: error: call to implicitly-deleted copy constructor of 'X'
    X y(std::move(x));
      ^ ~~~~~~~~~~~~
<source>:10:6: note: copy constructor is implicitly deleted because 'X' has a user-declared move assignment operator
  X &operator=(X &&);
     ^

472

I believe both of these cases are already covered by other tests in the suite (in fact that's how I found they were bad); I just wanted to have the known trouble spots tested in this single file for my own convenience. I'll remove these two "regression tests."

[• Quuxplusone]

clang-format.

[Rakete1111]

compiler-explorer-llvm-commit.sh

1

What's this file? A mistake?

include/clang/AST/DeclCXX.h

471

That comment misses a "or is a reference".

include/clang/Basic/DiagnosticSemaKinds.td

2942

Fair enough.

include/clang/Sema/Sema.h

4304

Nah, it's fine. There are lots of C++ specific things in AST/, because the AST nodes represent C++-y stuff. Trivially copyable is also part of QualType, even though it's C++ specific.

lib/Sema/SemaDecl.cpp

15823

You don't need this. This is already handled by CheckCompleteCXXClass.

lib/Sema/SemaDeclAttr.cpp

6481

Why is this attribute under "Microsoft Attributes"? ;)

lib/Sema/SemaDeclCXX.cpp

6157

Actually, nvm. I was thinking of calling a few functions instead of call LookupSpecialMember, but I forgot that those functions can only work if there was previously a call to LookupSpecialMember :/.

6166

Extra braces.

6187

This is dead code. Record never needs an implicit move constructor at this point, because either 1) it never did or 2) it was defined above by LookupSpecialMember.

12631

Same, already handled by CheckCompleteCXXClass.

test/SemaCXX/trivially-relocatable.cpp

43

Didn't know [[noreturn]] had it. Ah I see. Sold :)

430

Oops, you're right ofc. Sorry

[• Quuxplusone]

Further removal of dead code based on @Rakete1111's feedback.

compiler-explorer-llvm-commit.sh

1

Yeah, it's pipework for the Compiler Explorer integration. I manually deleted it from the previously uploaded diff, but forgot to delete it this time. You can ignore it.

include/clang/Sema/Sema.h

4304

Okay, moved!

lib/Sema/SemaDeclAttr.cpp

6481

I dunno, the random //comments seem pretty silly to me. There's nothing "Microsoft" about TrivialABI either (and no reason anyone should care, in this context, that EmptyBases or LayoutVersion are "Microsoft"). I just put it here because it's somewhat related to TrivialABI — and/or, to reduce code churn if anyone ever decides to Do The Right Thing and alphabetize these switch cases.

lib/Sema/SemaDeclCXX.cpp

6187

Confirmed that this code is never hit; and removed. Just for my own information: you're saying that the call to LookupSpecialMember on line 6179, even though it's looking up the destructor, will actually cause all the needsImplicitFootor flags to get resolved? And so also I guess I should never have been looking at those flags directly; I should have handled this case by calling LookupSpecialMember like I do on line 6196. Is that basically correct?

[Rakete1111]

lib/Sema/SemaDeclCXX.cpp

6187

No, not the 6179 one, but the one before it 6163. Yeah you could have :)

[Rakete1111]

lib/Sema/SemaDeclCXX.cpp

6091

Can you move this in ActOnFields? That way we avoid two iterations of the fields.

6187

Sorry for the noise, that isn't it because of the if statement right before 6163 :/. I was wrong...

Every implicit constructor is already defined before the call to CheckCompletedCXXClass (except if it's a template), so needsImplicitFootor is always false. This means that you can drop the if statement right before 6163, because it's always true.

I'm 99% sure of the previous paragraph. :)

[Rakete1111]

lib/Sema/SemaDeclCXX.cpp

6174

The call to isTemplateInstantiation is wrong. Consider:

template<class T>
struct [[trivially_relocatable]] A {
  T t;
};

struct X {
  X() = default;
  X(X &&) = delete;
};

A<X> d;
static_assert(!__is_trivially_relocatable(decltype(d))); // oops, fires

There is also no diagnostic saying that A<X> cannot be marked [[trivially_relocatable]].

6176

Record is never being defined at this point, even for templates. It also always has a definition AFAIK.

[• Quuxplusone]

lib/Sema/SemaDeclCXX.cpp

6091

Done. Btw, I notice that ActOnFields spends a lot of time doing dyn_cast<CXXRecordDecl>(Record) over and over. If I had commit privs, I'd refactor it to compute CXXRecordDecl *CXXRecord = dyn_cast_or_null<CXXRecordDecl>(Record); once at the very top of the function, and then use CXXRecord throughout.

6174

The absence of any diagnostics is intentional. We're saying that A is trivially relocatable except-of-course-when-it's-not-relocatable-at-all, similar to how templates currently work with constexpr.

However, the fact that __is_trivially_relocatable(A<X>) when !__is_constructible(A<X>, A<X>&&) does seem like a bug. I should probably move the isTemplateInstantiation check down to control just the diagnostic, eh?

6176

Yes, that matches my observations so far (but I'm running the tests again to confirm). I'd originally copied this formula from somewhere else, I forget where.

[Rakete1111]

lib/Sema/SemaDeclCXX.cpp

6091

Done. :) Thanks

6174

Yes, good idea.

[• Quuxplusone]

Correctly drop the attribute from non-relocatable instantiations of class templates (even though they don't print the diagnostic).

[• Quuxplusone]

lib/Sema/SemaDeclCXX.cpp

6187

I notice that test/SemaCXX/implicit-member-functions.cpp has started failing in my branch, although there's a *possibility* that that's due to a change in master. I'm going to investigate a little bit.

[• Quuxplusone]

Rebased, and ping!

[Rakete1111]

It would be nice to be able to diagnose X:

template <typename T>
struct Foo {
  struct [[trivially_relocatable]] X { // no warning
    X(X &&) = delete;
  };
};

Foo<int> f; // no warning
static_assert(!__is_trivially_relocatable(Foo<void>::X)); // ok

But otherwise, you might want to put the attribute in the clang namespace. LGTM then, but you'll want to wait for someone more senior than me to review (and possibly accept) it.

[• Quuxplusone]

A type with no move-constructor, and some non-defaulted copy-constructors (even if it *also* has some defaulted copy-constructors) should not be considered naturally trivially relocatable. The paper already said this, but the Clang patch was misimplemented.

Thanks to @Rakete1111 for either finding or inspiring this fix. :)

I suspect there may be some way of doing this without the extra bitflag, but I didn't immediately see how.

[• Quuxplusone]

Update to match the wording in D1144R0 draft revision 13. There's no longer any need to fail when we see a mutable member; on the other hand, we *always* need to perform the special member lookup to find out if our class is move-constructible and destructible.

[erichkeane]

You'll not be able to get the C++ spelling without it getting into the standard. Additionally, it seems easy enough to calculate upon need, so storing it in the AST is a waste. @aaron.ballman is likely another person who can review this.

docs/LanguageExtensions.rst

1093

How would this behave with unions? I don't see any exclusions happening on union-ness. A CXXRecordDecl can be a union as well as a class.

include/clang/AST/DeclCXX.h

474

Typically we'd have this calculated when requested rather than stored. I suspect using a bit for something like this isn't going to be terribly acceptable.

include/clang/Basic/Attr.td

2096

This spelling is almost definitely not acceptable until it is in the standard. Also, why specify that it was added in 2008?

include/clang/Basic/DiagnosticSemaKinds.td

8207

I'm shocked that there isn't a different diagnostic to do this same thing. @aaron.ballman likely knows better... I haven't seen the usage yet, but I presume you don't necessarily want a behavior that doesn't allow forward declarations.

lib/AST/Type.cpp

2234 ↗

(On Diff #161866)

You likely want to canonicalize here.

lib/Parse/ParseDeclCXX.cpp

3811

A note for future reviewers, after the C++11 spelling is removed, this likely needs to go as well.

[• Quuxplusone]

docs/LanguageExtensions.rst

1093

My intent is to make Clang's behavior match the wording in P1144R0; so, it should work for unions as well as for structs/classes. Any union which is trivially move-constructible and trivially destructible will be __is_trivially_relocatable. Any union which is non-trivially destructible *must* have a user-provided destructor, and therefore will *not* be __is_trivially_relocatable unless the user has annotated it with the attribute.
https://p1144.godbolt.org/z/F06TTQ

include/clang/AST/DeclCXX.h

474

You know better than I do; but I'm also not sure how to calculate it on request.

include/clang/Basic/Attr.td

2096

Agreed, it should be [[clang::trivially_relocatable]] for Clang's purposes. This spelling was because this patch came from the Godbolt Compiler Explorer patch where I wanted the shorter/future spelling for public relations reasons. :)
IIUC, the appropriate fix here is to change these two lines from

let Spellings = [CXX11<"", "trivially_relocatable", "200809">,
              CXX11<"clang", "trivially_relocatable">];

to

let Spellings = [Clang<"trivially_relocatable">,

I believe the "200809" was because I wanted it to be available in C++11 mode on Godbolt.

include/clang/Basic/DiagnosticSemaKinds.td

8207

I would be very happy to see this diagnostic get into trunk separately and earlier than D50119. There are some other diagnostics that could be merged with this one, e.g. [[noreturn]] needs a version of this diagnostic, and I believe [[clang::trivial_abi]] should have it added.

I don't know how to link to comments on Phabricator, but Ctrl+F downward for this example:

struct S { S(S&&); ~S(); };
std::vector<S> vec;
struct [[trivially_relocatable]] S;  // ha ha, now you have to re-do all of vector's codegen!

This is why it is important to diagnose and disallow "backward declarations." I don't particularly care about "forward declarations" (either to allow or disallow them). The attribute would end up getting used only on library types where IMHO nobody should ever be forward-declaring them anyway. E.g. it is not a good idea for a regular C++ programmer to forward-declare unique_ptr. But if there's a way to allow forward-declarations (when the type remains incomplete) while disallowing backward-declarations (adding the attribute to an already-complete type), then I will be happy to do it.

lib/AST/Type.cpp

2234 ↗

(On Diff #161866)

You mean QualType T = Context.getBaseElementType(getCanonicalType());?
I can do that. For my own edification (and/or a test case), in what way does the current code fail?

[dblaikie]

Hey @rjmccall - I'm trying to remember, but can't get it quite clear in my head. I seem to recall some discussion about trivial_abi not implying/being strong enough for all the cases that trivial_relocatable sounds like it covers? Do you happen to remember the distinction there (the summary in this patch ("the warranting attribute [[trivially_relocatable]], which is similar in spirit to [[trivial_abi]], in that it lets the programmer communicate back to the compiler that a certain user-defined type should be assumed to have this property even though it would not naturally have the property all else being equal.") doesn't sound like what I remember - but my memory is hazy)?

[erichkeane]

docs/LanguageExtensions.rst

1093

Makes sense.

include/clang/AST/DeclCXX.h

474

You'll end up just recursively walking the CXXRecordDecl upon application of the type trait, and need to check the things that make it NOT trivially relocatable.

I think it also extensively simplifies this patch, since none of the CXXRecordDecl functions are required (just the type-trait emission).

include/clang/Basic/Attr.td

2096

Yep, thats the suggested fix.

include/clang/Basic/DiagnosticSemaKinds.td

8207

Sure, I get that... I'm just surprised/amazed it doesn't already exist. Hopefully Aaron takes a look.

lib/AST/Type.cpp

2234 ↗

(On Diff #161866)

More like: QualType T = Context.getBaseElementType(*this).getCanonicalType();

This desugars typedefs in some cases, which could make the below fail.

Something like this: https://godbolt.org/z/-C-Onh

It MIGHT still pass here, but something else might canonicalize this along the way.

ADDITIONALLY, I wonder if this properly handles references? I don't think getBaseElementType will de-reference. You might want to do that as well.

[rjmccall]

In D50119#1297070, @dblaikie wrote:

Hey @rjmccall - I'm trying to remember, but can't get it quite clear in my head. I seem to recall some discussion about trivial_abi not implying/being strong enough for all the cases that trivial_relocatable sounds like it covers? Do you happen to remember the distinction there (the summary in this patch ("the warranting attribute [[trivially_relocatable]], which is similar in spirit to [[trivial_abi]], in that it lets the programmer communicate back to the compiler that a certain user-defined type should be assumed to have this property even though it would not naturally have the property all else being equal.") doesn't sound like what I remember - but my memory is hazy)?

trivial_abi permits annotated types to be passed and returned in registers, which is ABI-breaking. Skimming the blog post, it looks like trivially_relocatable does not permit this — it merely signifies that destruction is a no-op after a move construction or assignment. This is usefully different in the design space, since it means you can safely add the attribute retroactively to e.g. std::unique_ptr, and other templates can then detect that std::unique_ptr is trivially-relocatable and optimize themselves to use memcpy or realloc or whatever it is that they want to do. So in that sense trivial_abi is a *stronger* attribute, not a *weaker* one: the property it determines ought to imply trivially_relocatable.

The only interesting question in the language design that I know of is what happens if you put the attribute on a template that's instantiated to contain a sub-object that is definitely not trivially relocatable / trivial-ABI. For trivial_abi, we decided that the attribute is simply ignored — it implicitly only applies to specializations where the attribute would be legal. I haven't dug into the design enough to know what trivially_relocatable decides in this situation, but the three basic options are:

• the attribute always has effect and allows trivial relocation regardless of the subobject types; this is obviously unsafe, so it limits the safe applicability of the attribute to templates
• the attribute is ignored, like trivial_abi is
• the attribute is ill-formed, and you'll need to add a [[trivially_relocatable(bool)]] version to support templates

If there are corner-case differences beyond that, I have no particular objection to unifying the semantics so that trivial_abi is strictly stronger, although we should talk about it case-by-case.

test/SemaCXX/trivially-relocatable.cpp

43

I don't see any good reason to allow either this or [[trivial_abi]] on an arbitrary declaration of the type; it should have to be written on the definition. This also gives sensible semantics for class template specializations.

The intrinsic obviously has to require its operand type to be complete, and therefore there is a unique declaration which can have the attribute.

[• Quuxplusone]

docs/LanguageExtensions.rst

1096

@rjmccall wrote:

trivial_abi permits annotated types to be passed and returned in registers, which is ABI-breaking. Skimming the blog post, it looks like trivially_relocatable does not permit this — it merely signifies that destruction is a no-op after a move construction or assignment.

Not necessarily a "no-op"; my canonical example is a CopyOnlyCXX03SharedPtr which increments a refcount on construction and decrements on destruction. But move-construction plus destruction should "balance out" and result in no observable side effects.

This is usefully different in the design space, since it means you can safely add the attribute retroactively to e.g. std::unique_ptr, and other templates can then detect that std::unique_ptr is trivially-relocatable and optimize themselves to use memcpy or realloc or whatever it is that they want to do. So in that sense trivial_abi is a *stronger* attribute, not a *weaker* one: the property it determines ought to imply trivially_relocatable.

trivial_abi is an "orthogonal" attribute: you can have trivial_abi types with non-trivial constructors and destructors, which can have observable side effects. For example,

struct [[clang::trivial_abi]] DestructionAnnouncer {
    ~DestructionAnnouncer() { puts("hello!"); }
};

is trivial_abi (because of the annotation) yet not trivially relocatable, because its "move plus destroy" operation has observable side effects.

The only interesting question in the language design that I know of is what happens if you put the attribute on a template that's instantiated to contain a sub-object that is definitely not trivially relocatable / trivial-ABI. For trivial_abi, we decided that the attribute is simply ignored — it implicitly only applies to specializations where the attribute would be legal. I haven't dug into the design enough to know what trivially_relocatable decides in this situation, but the three basic options are:

• the attribute always has effect and allows trivial relocation regardless of the subobject types; this is obviously unsafe, so it limits the safe applicability of the attribute to templates
• the attribute is ignored, like trivial_abi is
• the attribute is ill-formed, and you'll need to add a [[trivially_relocatable(bool)]] version to support templates

What happens is basically the first thing you said, except that I disagree that it's "obviously unsafe." Right now, conditionally trivial relocation is possible via template metaprogramming; see the libcxx patch at e.g.
https://github.com/Quuxplusone/libcxx/commit/6524822c009e#diff-38adc80cec663f2f29c22e9ffc0de912
Since the attribute is an opt-in mechanism, it makes perfect sense to me that if you put it on a class (or class template), then it applies to the class, without any further sanity-checking by the compiler. The compiler has no reason to second-guess the programmer here.

However, there's one more interesting case. Suppose the programmer puts the attribute on a class that isn't relocatable at all! (For example, the union case @erichkeane mentioned, or a class type with a deleted destructor.) In that case, this patch *does* give an error... *unless* the class was produced by instantiating a template, in which case we *don't* give an error, because it's not the template-writer's fault.
https://p1144.godbolt.org/z/wSZPba

[rjmccall]

docs/LanguageExtensions.rst

1096

trivial_abi is an "orthogonal" attribute: you can have trivial_abi types with non-trivial constructors and destructors, which can have observable side effects.

Let me cut this conversation short. trivial_abi is not such an old and widely-established attribute that we are unable to revise its definition. I am comfortable making the same semantic guarantees for trivial_abi that you're making for trivially_relocatable, because I think it is in the language's interest for trivial_abi to be strictly stronger than trivially_relocatable.

What happens is basically the first thing you said, except that I disagree that it's "obviously unsafe."

Under your semantics, the attribute is an unchecked assertion about all of a class's subobjects. A class template which fails to correctly apply the template metaprogramming trick to all of its dependently-typed subobjects — which can be quite awkward because it creates an extra dimension of partial specialization, and which breaks ABI by adding extra template parameters — will be silently miscompiled to allow objects to be memcpy'ed when they're potentially not legal to memcpy. That is a footgun, and it is indeed "obviously unsafe".

Now, it's fair to say that it's unsafe in a useful way: because the attribute isn't checked, you can wrap a type you don't control in a trivially_relocatable struct and thereby get the advantages of triviality on the wrapper. The model used by trivial_abi doesn't allow that. But I feel pretty strongly that that is not the right default behavior for the language.

[• Quuxplusone]

docs/LanguageExtensions.rst

1096

Under your semantics, the attribute is an unchecked assertion about all of a class's subobjects.

The attribute is an unchecked assertion about the class's special member functions. The attribute doesn't have anything to do with subobjects, period.
Vice versa, the property currently expressed by "IsNaturallyTriviallyRelocatable" is deduced from all of the class's subobjects. The programmer can overrule the "natural" property in an "unnatural" way by annotating their class with the attribute.

And we know this is true because it is possible to make a trivially-relocatable class type containing non-trivially-relocatable members (e.g. a class having a member of type boost::interprocess::offset_ptr), and vice versa it is possible to make a non-trivially-relocatable class containing trivially-relocatable members (e.g. boost::interprocess::offset_ptr itself, which has only one member, of integral type).

A class template which fails to correctly apply the template metaprogramming trick to all of its dependently-typed subobjects — which can be quite awkward because it creates an extra dimension of partial specialization

Agreed that it's awkward. The libc++ implementation was awkward, but definitely not challenging. The only thing that makes it at all tricky in the STL is that the STL allocator model permits fancy "pointer" types that can make e.g. std::vector non-trivially relocatable. If it weren't for fancy pointers, you wouldn't need the extra dimension.

and which breaks ABI by adding extra template parameters

The libc++ implementation does not break ABI. The extra template parameter is concealed in a private base class.
https://github.com/Quuxplusone/libcxx/commit/6524822c009e#diff-38adc80cec663f2f29c22e9ffc0de912

I feel pretty strongly that that is not the right default behavior for the language.

Can you elaborate on that feeling (maybe in private email)? My intent with P1144 is that no industry programmer should ever see this attribute; the right default for industry programmers is to use the Rule of Zero. The reason we need the attribute is as an opt-in mechanism for the implementor of unique_ptr, shared_ptr, vector, and so on, so that the end-user can just use the Rule of Zero and everything will work fine. End-users shouldn't be messing with attributes.

lib/AST/Type.cpp

2234 ↗

(On Diff #161866)

ADDITIONALLY, I wonder if this properly handles references? I don't think getBaseElementType will de-reference. You might want to do that as well.

I actually don't want references to be stripped here: int& should come out as "not trivially relocatable" because it is not an object type.
https://p1144.godbolt.org/z/TbSsOA

[erichkeane]

lib/AST/Type.cpp

2234 ↗

(On Diff #161866)

Ah, I see. For some reason I had it in my mind that you wanted to follow references.

[rjmccall]

docs/LanguageExtensions.rst

1096

And we know this is true because it is possible to make a trivially-relocatable class type containing non-trivially-relocatable members (e.g. a class having a member of type boost::interprocess::offset_ptr), and vice versa it is possible to make a non-trivially-relocatable class containing trivially-relocatable members (e.g. boost::interprocess::offset_ptr itself, which has only one member, of integral type).

Why would a class containing a member of type boost::interprocess::offset_ptr be trivially-relocatable? If you actually trivially relocate an object of the class, the pointer will not be rebased and so will be invalidated. It would have to be an offset_ptr where you happen to know that the referent will always be copied simultaneously, e.g. because it's a member of the object itself. Of course that's possible, but it's also such a corner case that we shouldn't balk at saying that the programmer ought to be more explicit about recognizing it.

Agreed that it's awkward. The libc++ implementation was awkward, but definitely not challenging. The only thing that makes it at all tricky in the STL is that the STL allocator model permits fancy "pointer" types that can make e.g. std::vector non-trivially relocatable. If it weren't for fancy pointers, you wouldn't need the extra dimension.

Sure. My point about the awkwardness is quite narrow: making the attribute take a bool argument is just a superior way of managing this over requiring a partial specialization. Several other language attributes have been heading in this same direction.

The libc++ implementation does not break ABI. The extra template parameter is concealed in a private base class.

Ah, apologies.

My intent with P1144 is that no industry programmer should ever see this attribute; the right default for industry programmers is to use the Rule of Zero. ... End-users shouldn't be messing with attributes.

Neither of these statements matches my experience. This is an "expert" feature to be sure, but the C++ community is full of experts who write their own rule-of-five types and who will happily use whatever attributes are available to them to make them faster.

Also, I assume you are intending for this attribute to be standardized eventually, which will greatly expand its reach.

[• Quuxplusone]

docs/LanguageExtensions.rst

1096

Why would a class containing a member of type boost::interprocess::offset_ptr be trivially-relocatable? If you actually trivially relocate an object of the class, the pointer will not be rebased and so will be invalidated. It would have to be an offset_ptr where you happen to know that the referent will always be copied simultaneously, e.g. because it's a member of the object itself.

Exactly! (And to preserve the class invariant, you'd have to add a copy-constructor.)

Of course that's possible, but it's also such a corner case that we shouldn't balk at saying that the programmer ought to be more explicit about recognizing it.

Exactly — and the way for the programmer to explicitly recognize (or I say "warrant") that their class has the property is for them to annotate it with [[trivially_relocatable]]. So I guess maybe I don't understand what you mean by "more explicit"?

making the attribute take a bool argument is just a superior way of managing this

That's possible, but it's also possible that it would increase the complexity of parsing attributes for some implementations. I mean, we're talking about something like the following, right? (Using the libc++ patch as the example, but I've de-uglified some of the names.) So I think it's a tradeoff and I'm ambivalent about it, so far. (This is one of the straw poll questions in P1144R0.)

template <class T, class A = allocator<T>>
class [[trivially_relocatable(__deque_base<T, A>::__allow_trivial_relocation::value)]] deque
    : private __deque_base<T, A>

This is an "expert" feature to be sure, but the C++ community is full of experts who write their own rule-of-five types and who will happily use whatever attributes are available to them to make them faster.

Agreed. But the C++ community is also full of working programmers who just write simple code with strings and vectors. :) I want [[trivially_relocatable]] to be approximately as frequently seen in real codebases as [[no_unique_address]] — i.e. maybe a couple times in that smart-pointer library the contractor wrote, but nowhere near the user code. If it's seen frequently in user code, then we've failed those users.

[rjmccall]

docs/LanguageExtensions.rst

1096

Exactly! (And to preserve the class invariant, you'd have to add a copy-constructor.)

But then it still wouldn't be trivially relocatable, because there's user-defined code that has to run to copy it correctly. The only way such a type could ever be meaningfully trivially relocatable outside of obviously unknowable external conditions is if it has fields that it never uses after it's been relocated.

Exactly — and the way for the programmer to explicitly recognize (or I say "warrant") that their class has the property is for them to annotate it with [[trivially_relocatable]]. So I guess maybe I don't understand what you mean by "more explicit"?

I think it is far more likely that some well-intentioned library author will add [[trivially_relocatable]] incorrectly than that they'll actually intend to override the trivial relocatability of their subobjects.

By "more explicit", I was suggesting that you add some kind of "force" syntax to the attribute (straw-man suggestion: [[trivially_relocatable!]]). Without the force, the attribute will negate non-triviality from special members in the class but won't override natural non-triviality from subobjects.

That's possible, but it's also possible that it would increase the complexity of parsing attributes for some implementations.

All conforming implementations have to do the work to support things like this already because of alignas, noexcept, etc.

Agreed. But the C++ community is also full of working programmers who just write simple code with strings and vectors. :) I want [[trivially_relocatable]] to be approximately as frequently seen in real codebases as [[no_unique_address]] — i.e. maybe a couple times in that smart-pointer library the contractor wrote, but nowhere near the user code. If it's seen frequently in user code, then we've failed those users.

I think you are underestimating the sophistication of "working programmers" and overestimating the sophistication of library developers. A [[trivially_relocatable]] that doesn't override subobject triviality is far easier for library authors to use correctly and will avoid an endless cascade of oversights.

Case in point, every single subtle thing that you had to anticipate and call out in your patch to std::deque would just go away if the language simply propagated non-triviality of subobjects.

[• Quuxplusone]

docs/LanguageExtensions.rst

1096

I think it is far more likely that some well-intentioned library author will add [[trivially_relocatable]] incorrectly than that they'll actually intend to override the trivial relocatability of their subobjects.

But overriding "natural" non-trivial relocatability is precisely the reason for P1144 [[trivially_relocatable]]! If you just have a plain old Rule-of-Zero object with trivially relocatable subobjects, and you want your object to be trivially relocatable as a result, the core language takes care of that for you (just like with trivial {con,de}structibility and trivial-abi-ness: a Rule-of-Zero composite of trivial objects is itself trivial). The only use-case for the [[trivially_relocatable]] attribute is when you are trying to tell the compiler that you know exactly what you're doing. (Which is why normal working programmers won't generally use it.)

By "more explicit", I was suggesting that you add some kind of "force" syntax to the attribute (straw-man suggestion: [[trivially_relocatable!]]). Without the force, the attribute will negate non-triviality from special members in the class but won't override natural non-triviality from subobjects.

Can you give an example of how it would work with deque, for example? What part of the deque implementation would become simpler, in exchange for this added complexity of specification?

You say:

Case in point, every single subtle thing that you had to anticipate and call out in your patch to std::deque would just go away if the language simply propagated non-triviality of subobjects.

But I don't understand what you mean by this. Are you saying that you want to be able to write class [[trivially_relocatable]] deque { ... } to mean that you want the trivially-relocatable-ness of deque to match the trivially-relocatable-ness of its least relocatable subobject? But then for example in the libc++ patch, I'd either have to go out of my way to make sure that __map and __deque_base were trivially relocatable (which would require metaprogramming similar to what's there now, except one turtle lower down in the stack — or were you thinking of adding [[trivially_relocatable]] to all the turtles in the stack?), or else I'd have to use class [[trivially_relocatable!]] deque to overrule the non-trivial-relocatability of deque's __map and __deque_base subobjects, in which case I'd still need the four lines you were trying to eliminate.
https://github.com/Quuxplusone/libcxx/commit/6524822c009e#diff-38adc80cec663f2f29c22e9ffc0de912R957

My kneejerk reaction is that it is a bad idea to have two similarly-named things, one of which has subtly correct semantics and the other of which has subtly incorrect semantics, especially when it's not obvious which one is correct in any specific situation. (OT: This is basically the reason behind my P1155.) But even beyond that general reaction, I specifically have not understood how [[trivially_relocatable!]] would help the programmer of deque.

All conforming implementations have to do the work to support things like this already because of alignas, noexcept, etc.

Yes, but those aren't attributes, grammatically... Well, I guess there is already a standard grammar for parsing unknown attributes in terms of balanced-token-seq, and I can't think of any boolean expression that is not a balanced-token-seq, so okay, I'll retract my FUD over the technical difficulties of [[trivially_relocatable(bool)]]. I am still ambivalent as to whether it'd be a good tradeoff. (Complexity of specification and arcane terseness of code, versus simplicity of specification and boilerplate verbosity of code.)

[rjmccall]

docs/LanguageExtensions.rst

1096

But then for example in the libc++ patch, I'd either have to go out of my way to make sure that map and deque_base were trivially relocatable (which would require metaprogramming similar to what's there now, except one turtle lower down in the stack — or were you thinking of adding [[trivially_relocatable]] to all the turtles in the stack?),

You would need the attribute only at the level(s) that actually defined the special members; all the "rule of zero" levels would of course propagate trivial relocatability.

I specifically have not understood how [[trivially_relocatable!]] would help the programmer of deque.

It wouldn't. I don't think it's worth adding at all, actually. I'm just saying it's possible to add it if you really think that "trivially-relocatable type with a non-trivially-relocatable subobject" is a relevant use case.

Yes, but those aren't attributes, grammatically...

True, alignas is not spelled as an attribute (which I constantly forget — it was a very odd decision).

Recent drafts of the standard do include expects and ensures, which take arbitrary expressions as operands. The spelling's a bit different from the strawman I suggested, though: it's [[expects: x > 0]].

I can't think of any boolean expression that is not a balanced-token-seq

That's not a coincidence: all expressions are balanced-token-seqs, as is every other major production in the C++ grammar. The grammar allows a balanced-token-seq there precisely because the committee was anticipating attributes that take arbitrarily complex expressions as operands, which are quite common in all the vendor extensions they were looking at.

I am still ambivalent as to whether it'd be a good tradeoff. (Complexity of specification and arcane terseness of code, versus simplicity of specification and boilerplate verbosity of code.)

My two pieces of feedback are separable. Even with your preferred semantics, your proposal would be much better if the attribute followed a noexcept-like design where it can optionally take a boolean argument. In fact, adding that is much more important with your semantics for the attribute since so many use sites will be conditional.

Also, I don't think your semantics actually give rise to a simpler specification. The specification has to formalize "naturally trivially relocatable" in either case because it's important for rule-of-zero types to be trivially relocatable if all their subobjects are. My suggested semantics are basically just that the attribute doesn't override the natural relocatability of the type; it only prevents the presence of non-trivial special members from changing it. That's a short paragraph in the spec in exchange for an attribute that's much less prone to errors in corner cases (e.g. ignoring the possibility of non-trivial pointer types) and which rarely needs to be explicitly conditionalized. But it does make the (unsafe) override case impossible, although, again, I think the motivation for that is pretty weak.

[aaron.ballman]

include/clang/Basic/Attr.td

2096

to
let Spellings = [Clang<"trivially_relocatable">,

Close, but since this attribute has no meaning in C mode, it should be let Spellings = [Clang<"trivially_relocatable", 0>,

include/clang/Basic/DiagnosticSemaKinds.td

8207

Yeah, I'm also surprised this doesn't already exist, but... it doesn't seem to. We have err_noreturn_missing_on_first_decl, err_carries_dependency_missing_on_first_decl, and err_internal_linkage_redeclaration to all do the same thing.

[• Quuxplusone]

docs/LanguageExtensions.rst

1096

I don't think your semantics actually give rise to a simpler specification. The specification has to formalize "naturally trivially relocatable" in either case

I think the spec is already simple: P1144R0 section 4.4. The paper spec doesn't need to formalize "naturally trivially relocatable"; that's an artifact of the Clang implementation.

My suggested semantics are basically just that the attribute doesn't override the natural relocatability of the type; it only prevents the presence of non-trivial special members from changing it.

In the Clang patch, I'm currently using "naturally trivially relocatable" to mean "has defaulted special members and all subobjects are trivially relocatable." (So when I say "Xly Yly Zable," it implies "Yly Zable" as well as "Zable".) IIUC, you've been using it to mean "all subobjects are trivially relocatable but maybe there are user-provided special members"? I.e., if I had a class type with no data members, a user-defined destructor, and no attribute, you would have considered that class type to be "naturally trivially relocatable, but not trivially relocatable"? ("Xly Yly Zable" wouldn't imply "Yly Zable"?)

if you really think that "trivially-relocatable type with a non-trivially-relocatable subobject" is a relevant use case

Yes, that use-case is absolutely indispensable. For example, we must provide a way for the programmer to express that struct Widget { boost::shared_ptr<Widget> sp; }; is trivially relocatable. (Without upgrading our Boost distribution. ;)) In P1144R0, we can do that by putting the attribute on Widget, or by putting the attribute on an "extremely loud and incredibly narrow" wrapper class:
https://quuxplusone.github.io/blog/2018/10/04/trivially-relocatable-faq/#what-if-i-use-the-trivially_relo

[dblaikie]

docs/LanguageExtensions.rst

1096

"Yes, that use-case is absolutely indispensable. For example, we must provide a way for the programmer to express that struct Widget { boost::shared_ptr<Widget> sp; }; is trivially relocatable. (Without upgrading our Boost distribution. ;)) "

That's something I'd disagree with on first blush - why is this functionality absolutely indispensable?

I'd be pretty concerned about people effectively annotating types they don't own with a guarantee they probably can't actually make - how's someone going to make the determination that a third party type is safe to (indirectyl) add this attribute to? & what if that type changes in the future (or has a debug mode, or something else the user hasn't anticipated) - and it only solves the cases where the third party type is embedded within a user type - which, for something like shared_ptr misses lots of cases where the shared_ptr itself is passed around.

To me that doesn't seem like a "must have" feature - compared to the ability to annotate a type where I've written some user-defined special members, but I know/can guarantee (until I change the class in such a way that it doesn't have that feature - at which point I can remove the attribute too, because I control both implementation and attribution) that move+destroy is semantically equivalent to memcpy.

[• Quuxplusone]

docs/LanguageExtensions.rst

1096

Yes, that use-case is absolutely indispensable. For example, we must provide a way for the programmer to express that struct Widget { boost::shared_ptr<Widget> sp; }; is trivially relocatable. (Without upgrading our Boost distribution. ;))

That's something I'd disagree with on first blush - why is this functionality absolutely indispensable?

Because it's close to functionality that people are trying to use today (e.g. Folly uses FOLLY_ASSUME_RELOCATABLE to apply trivial relocatability onto non-annotated types such as boost::shared_ptr or std::string). Admittedly, this is a source of bugs. But without it, I think people would just ask to have it — because it's the thing that gives them the codegen they want.

[dblaikie]

docs/LanguageExtensions.rst

1096

I guess one of the reasons they're in this situation is that there isn't a standardized form that library authors can use - so they're stuck working around that on their end? & that wouldn't be such an issue if there was a standard way to do this that the compilers understood/respected, rather than only done on a per-library basis for cases where the library is implementing the relocation (rather than on ABI boundaries, etc).

[rjmccall]

docs/LanguageExtensions.rst

1096

I think the spec is already simple: P1144R0 section 4.4. The paper spec doesn't need to formalize "naturally trivially relocatable"; that's an artifact of the Clang implementation.

I misunderstood how you were using "naturally trivially relocatable", sorry. What I mean is that the specification has to formalize rules for deciding and propagating trivial relocatability for arbitrary class types, which is the main source of complexity in the specification.

if I had a class type with no data members, a user-defined destructor, and no attribute, you would have considered that class type to be "naturally trivially relocatable, but not trivially relocatable"

Correct. And "naturally trivially relocatable" in this sense is not a generally-interesting property — it's only used as part of deciding trivial relocability in the presence of the attribute.

I completely agree with Dave's points. The short-term needs of programmers who want specific optimizations but are reluctant to make trivial changes to their local copies of Boost do not seem like they should dictate the long-term language design.

[• Quuxplusone]

Use [[clang::trivially_relocatable]] instead of [[trivially_relocatable]].
Canonicalize in QualType::isTriviallyRelocatableType.
Slight wording tweaks to the documentation.

[• Quuxplusone]

include/clang/AST/DeclCXX.h

474

@erichkeane: I tried to follow this advice tonight, but I can't find any other type trait in Clang that is implemented the way you described. Every other type trait seems to be implemented in exactly the way I did it: isPolymorphic, isAbstract, isStandardLayoutType, isTrivialType, isAggregateType, hasTrivialDefaultConstructor... they all seem to occupy a bit in CXXRecordDecl. None of them seem to be computed by walking the fields() of a CXXRecordDecl on the fly — and that makes sense to me, because that would be an arbitrarily slow operation, whereas keeping the bit is O(1) no matter how many times the result is asked for.
If calculating traits on request is "typical," can you point me to somewhere in Clang where it happens, so that I can try to copy how they do it?

[rjmccall]

include/clang/AST/DeclCXX.h

474

Most of the other unary traits actually have to be computed just for at least some aspect of normal compiler operation, but that's not true of this, so I can understand the desire to avoid burdening the logic. In this case, though, I think it's fine because it's pretty trivial to collect this when we're already collecting almost all of the relevant information as part of the trivial-ABI calculation. In fact, it meshes well with some things we've thought about doing for some non-standard sources of non-triviality; CC'ing Akira Hatanaka for his thoughts.

[• Quuxplusone]

lib/Parse/ParseDeclCXX.cpp

3811

With this line:

struct [[clang::trivially_relocatable()]] A {};
// expected-error@-1 {{attribute 'trivially_relocatable' cannot have an argument list}}
struct [[clang::trivially_relocatable(42)]] B {};
// expected-error@-1 {{attribute 'trivially_relocatable' cannot have an argument list}}

Without this line:

struct [[clang::trivially_relocatable()]] A {};
struct [[clang::trivially_relocatable(42)]] B {};
// expected-error@-1 {{'trivially_relocatable' attribute takes no arguments}}

IMO the former behavior (with this line) is much preferable to the latter behavior. I think I wish this switch statement included all attributes!

[• Quuxplusone]

Implement [[clang::maybe_trivially_relocatable]] along the lines suggested by @rjmccall. The idea is that there are two levels of "opt-in-ness."

The first level, [[clang::maybe_trivially_relocatable]], means "I warrant that even though I may have user-provided, non-defaulted, special member functions, I have designed them so that my relocation operation will not do anything substantially different from memberwise relocation." So if all of my member+base subobjects are trivially relocatable (and not mutable and not volatile), then I myself will be trivially relocatable.

The second level, [[clang::trivially_relocatable]], means "I warrant that even though I may have user-provided, non-defaulted, special member functions, and even though I may have non-trivially relocatable (or mutable or volatile) subobjects, I have designed them so that my relocation operation will not do anything substantially different from memcpy." So I myself will be trivially relocatable no matter what my subobjects claim about themselves. Significantly, this means that I can write a class that overrules a decision made by one of its members.

• I can make a TriviallyRelocatableWidget that encloses a heap and a bunch of offset_ptrs into that heap, even though a single offset_ptr in isolation is not trivially relocatable.
• I can make a TriviallyRelocatableWidget that encloses a boost::shared_ptr<int>, even though the maintainer of boost::shared_ptr may not have marked boost::shared_ptr as trivially relocatable.
• (Of dubious usefulness) I can make a BaseClass that is not marked trivially relocatable, and then make a TriviallyRelocatableDerivedClass that strengthens the guarantees of its BaseClass while remaining Liskov-substitutable for it.

Now that [[clang::maybe_trivially_relocatable]] is implemented, we can see if it does actually simplify the libc++ patch. I will try to get to that tonight. The current libc++ patch is here:
https://github.com/Quuxplusone/libcxx/tree/trivially-relocatable

[• Quuxplusone]

In D50119#1302134, @Quuxplusone wrote:

Now that [[clang::maybe_trivially_relocatable]] is implemented, we can see if it does actually simplify the libc++ patch. I will try to get to that tonight.

Here is deque implemented with [[trivially_relocatable]]: https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...1df78ab704b8b3d5a5e225a7624eb5fe10e3f401
And deque implemented with [[maybe_trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...5945ccee2f7bb30fbb4e3a7cf9308ee8145c758b

Here is unordered_set implemented with [[trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...8ddd963c738cef0c3ad5b314746ac5ddc2415751
And unordered_set implemented with [[maybe_trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...0e8ddfe99145fe69a18a3fd8929674d937f22b99

The [[maybe_trivially_relocatable]] patches are much shorter (18 and 30 lines) than the [[trivially_relocatable]] patches (78 and 145 lines). However, it's worth noting that 56 of the lines in the unordered_set [[trivially_relocatable]] patch are there only to deal with C++03's lack of using-constructor declarations, and would disappear if we were working on a C++11-only codebase.

In the unordered_set [[trivially_relocatable]] patch, I use the "triviality-forcing wrapper" pattern which would not be possible with [[maybe_trivially_relocatable]]. This saves me from having to pipe the attribute down through unique_ptr and __bucket_list_deallocator.

In the unordered_set [[maybe_trivially_relocatable]] patch, I must wrap the attribute in a macro _LIBCPP_MAYBE_TRIVIALLY_RELOCATABLE_UNLESS_DEBUG. Without this caveat, I would have ended up with unsafe behavior in debug mode. The unordered_set [[trivially_relocatable]] patch does not have this danger; the fact that we break the Rule of Zero in debug mode is sufficient to disable trivial relocatability.

In the unordered_set [[maybe_trivially_relocatable]] patch, I must either pipe the attribute down through unique_ptr, or else give up using unique_ptr in __hash_table. I chose to modify unique_ptr; but note that many working programmers wouldn't have this luxury. In the unordered_set [[trivially_relocatable]] patch, I don't need to modify unique_ptr; I just use the "triviality-forcing wrapper" pattern.

In the unordered_set [[trivially_relocatable]] patch, I chose to "cheat" and write is_trivially_relocatable<__next_pointer>::value && is_trivially_relocatable<__pointer_allocator>::value instead of piping trivial relocatability down through __bucket_list_deallocator. If I'd done that, the patch would have gotten even longer. (And for no benefit, since __bucket_list_deallocator is a private helper class never directly touched by the user.)

So, both ways have their "cheats" and both ways have their dangers-of-unsafe-behavior. The [[maybe_trivially_relocatable]] patches are significantly shorter. The [[trivially_relocatable]] patches touch fewer classes. I'm still more comfortable with [[trivially_relocatable]], but I can see the appeal of terser code.

I still believe it is impossible to implement std::optional with only [[maybe_trivially_relocatable]].

[rjmccall]

In D50119#1303423, @Quuxplusone wrote:

In the unordered_set [[maybe_trivially_relocatable]] patch, I must wrap the attribute in a macro _LIBCPP_MAYBE_TRIVIALLY_RELOCATABLE_UNLESS_DEBUG. Without this caveat, I would have ended up with unsafe behavior in debug mode. The unordered_set [[trivially_relocatable]] patch does not have this danger; the fact that we break the Rule of Zero in debug mode is sufficient to disable trivial relocatability.

Can you elaborate? Providing a non-defaulted copy/move constructor or destructor should make an unannotated class non-trivially-relocatable under both rules.

In the unordered_set [[maybe_trivially_relocatable]] patch, I must either pipe the attribute down through unique_ptr, or else give up using unique_ptr in __hash_table. I chose to modify unique_ptr; but note that many working programmers wouldn't have this luxury. In the unordered_set [[trivially_relocatable]] patch, I don't need to modify unique_ptr; I just use the "triviality-forcing wrapper" pattern.

Sure, this is an acknowledged downside of [[maybe_trivially_relocatable]] for third-party programmers.

I still believe it is impossible to implement std::optional with only [[maybe_trivially_relocatable]].

This might also need elaboration.

[• Quuxplusone]

In D50119#1303577, @rjmccall wrote:

In D50119#1303423, @Quuxplusone wrote:

In the unordered_set [[maybe_trivially_relocatable]] patch, I must wrap the attribute in a macro _LIBCPP_MAYBE_TRIVIALLY_RELOCATABLE_UNLESS_DEBUG. Without this caveat, I would have ended up with unsafe behavior in debug mode. The unordered_set [[trivially_relocatable]] patch does not have this danger; the fact that we break the Rule of Zero in debug mode is sufficient to disable trivial relocatability.

Can you elaborate? Providing a non-defaulted copy/move constructor or destructor should make an unannotated class non-trivially-relocatable under both rules.

In the patch I was describing, I had annotated unordered_set. However, your comment made me realize that after annotating __hash_table, I could completely drop the [[maybe_trivially_relocatable]] annotation on unordered_set, and hide its move-constructor behind #if _LIBCPP_DEBUG_LEVEL >= 2 the same way I do in the [[trivially_relocatable]] patch. So I retract that complaint.

Here is unordered_set implemented with [[trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...8ddd963c738cef0c3ad5b314746ac5ddc2415751
And here's the new and improved version of unordered_set implemented with [[maybe_trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...0e8ddfe99145fe69a18a3fd8929674d937f22b99

I still believe it is impossible to implement std::optional with only [[maybe_trivially_relocatable]].

This might also need elaboration.

Because __optional_destruct_base contains an anonymous union member, and that union type is not destructible; therefore that union type is not trivially relocatable; therefore __optional_destruct_base contains a member of non-trivially-destructible [OOPS: I mean non-trivially-relocatable] type. However, I'm working on changing my patch to make anonymous unions "see-through" in this respect, so that that union's non-destructibility doesn't interfere with the [[maybe_trivially_relocatable]]ity of its enclosing class type, as long as all the members of the union are trivially relocatable. This might fix optional. I'm not sure yet.

[rjmccall]

In D50119#1303662, @Quuxplusone wrote:

In D50119#1303577, @rjmccall wrote:

In D50119#1303423, @Quuxplusone wrote:

In the unordered_set [[maybe_trivially_relocatable]] patch, I must wrap the attribute in a macro _LIBCPP_MAYBE_TRIVIALLY_RELOCATABLE_UNLESS_DEBUG. Without this caveat, I would have ended up with unsafe behavior in debug mode. The unordered_set [[trivially_relocatable]] patch does not have this danger; the fact that we break the Rule of Zero in debug mode is sufficient to disable trivial relocatability.

Can you elaborate? Providing a non-defaulted copy/move constructor or destructor should make an unannotated class non-trivially-relocatable under both rules.

In the patch I was describing, I had annotated unordered_set. However, your comment made me realize that after annotating __hash_table, I could completely drop the [[maybe_trivially_relocatable]] annotation on unordered_set, and hide its move-constructor behind #if _LIBCPP_DEBUG_LEVEL >= 2 the same way I do in the [[trivially_relocatable]] patch. So I retract that complaint.

Here is unordered_set implemented with [[trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...8ddd963c738cef0c3ad5b314746ac5ddc2415751
And here's the new and improved version of unordered_set implemented with [[maybe_trivially_relocatable]]:
https://github.com/Quuxplusone/libcxx/compare/0533994b3fcb115fdd89a38f80f737de8e76d023...0e8ddfe99145fe69a18a3fd8929674d937f22b99

Okay, thank you.

I still believe it is impossible to implement std::optional with only [[maybe_trivially_relocatable]].

This might also need elaboration.

Because __optional_destruct_base contains an anonymous union member, and that union type is not destructible; therefore that union type is not trivially relocatable; therefore __optional_destruct_base contains a member of non-trivially-destructible type. However, I'm working on changing my patch to make anonymous unions "see-through" in this respect, so that that union's non-destructibility doesn't interfere with the [[maybe_trivially_relocatable]]ity of its enclosing class type, as long as all the members of the union are trivially relocatable. This might fix optional. I'm not sure yet.

Ah, that makes sense. And yeah, that seems like the right rule for unions. I really appreciate you putting the effort into exploring this part of the design space.

[• Quuxplusone]

In D50119#1303720, @rjmccall wrote:

In D50119#1303662, @Quuxplusone wrote:

I still believe it is impossible to implement std::optional with only [[maybe_trivially_relocatable]].

This might also need elaboration.

Because __optional_destruct_base contains an anonymous union member, and that union type is not destructible; therefore that union type is not trivially relocatable; therefore __optional_destruct_base contains a member of non-trivially-destructible type. However, I'm working on changing my patch to make anonymous unions "see-through" in this respect, so that that union's non-destructibility doesn't interfere with the [[maybe_trivially_relocatable]]ity of its enclosing class type, as long as all the members of the union are trivially relocatable. This might fix optional. I'm not sure yet.

Ah, that makes sense. And yeah, that seems like the right rule for unions. I really appreciate you putting the effort into exploring this part of the design space.

I think it's part of the right rule, but it's not enough, either. Consider:

struct [[clang::maybe_trivially_relocatable]] DestroyBase {
    int i;
    DestroyBase(DestroyBase&&) = delete;
    ~DestroyBase();
};
struct [[clang::maybe_trivially_relocatable]] MoveBase : DestroyBase {
    MoveBase(MoveBase&&);
};

static_assert(not std::is_move_constructible_v<DestroyBase>); //, therefore
static_assert(not std::is_relocatable_v<DestroyBase>); //, therefore
static_assert(not std::is_trivially_relocatable_v<DestroyBase>); //; and since MoveBase now has a base class of non-trivially-relocatable type,
static_assert(not std::is_trivially_relocatable_v<MoveBase>);

So maybe you need a notion like "a class is BlahBlah if all of its direct members are BlahBlah, and either it is annotated [[maybe_trivially_relocatable]] or else it has no non-defaulted move or destroy operations." And then "a move-constructible, destructible class is trivially relocatable if it is BlahBlah, or if it is annotated [[trivially_relocatable]]." And then a class like DestroyBase can be "BlahBlah but not move-constructible," and if it's placed inside MoveBase, and MoveBase is both annotated and move-constructible, then MoveBase becomes trivially relocatable.

This does feel like it would be twice as hard to specify in the Standard, because I think I'd have to specify both the rules for BlahBlah and the rules for "trivially relocatable."

I'm also extremely concerned about the philosophical correctness of separating BlahBlahness from actual physical relocatability. What does it mean, abstractly, to say that "DestroyBase is not even moveable at all, but if it were, I'm confident that its relocation operation would be trivial"? That's some weird counterfactual logic that forces the writer of the class (DestroyBase in this case, but also e.g. lock_guard) to think about how their class might get used downstream, and what the class's hypothetical invariants might be, under an operation (move+destroy) that it itself does not claim to support.

The benefit of my original "second-level" [[trivially_relocatable]] attribute is that it puts all the responsibility in a single very high-level place. optional is the thing that knows exactly when it's trivially relocatable (or at least can make a conservative guess, which might boil down to "I'm never trivially relocatable"), so optional is the thing that should get the attribute.

If I get time today I'll try adding the boolean argument to the attribute, and do the libc++ patches that way for comparison.

[rjmccall]

In D50119#1305503, @Quuxplusone wrote:

In D50119#1303720, @rjmccall wrote:

In D50119#1303662, @Quuxplusone wrote:

I still believe it is impossible to implement std::optional with only [[maybe_trivially_relocatable]].

This might also need elaboration.

Because __optional_destruct_base contains an anonymous union member, and that union type is not destructible; therefore that union type is not trivially relocatable; therefore __optional_destruct_base contains a member of non-trivially-destructible type. However, I'm working on changing my patch to make anonymous unions "see-through" in this respect, so that that union's non-destructibility doesn't interfere with the [[maybe_trivially_relocatable]]ity of its enclosing class type, as long as all the members of the union are trivially relocatable. This might fix optional. I'm not sure yet.

Ah, that makes sense. And yeah, that seems like the right rule for unions. I really appreciate you putting the effort into exploring this part of the design space.

I think it's part of the right rule, but it's not enough, either. Consider:

struct [[clang::maybe_trivially_relocatable]] DestroyBase {
    int i;
    DestroyBase(DestroyBase&&) = delete;
    ~DestroyBase();
};
struct [[clang::maybe_trivially_relocatable]] MoveBase : DestroyBase {
    MoveBase(MoveBase&&);
};

static_assert(not std::is_move_constructible_v<DestroyBase>); //, therefore
static_assert(not std::is_relocatable_v<DestroyBase>); //, therefore
static_assert(not std::is_trivially_relocatable_v<DestroyBase>); //; and since MoveBase now has a base class of non-trivially-relocatable type,
static_assert(not std::is_trivially_relocatable_v<MoveBase>);

Hmm. I don't remember what we do in this case for trivial_abi (which does need to address it because it's possible to return types like DestroyBase). It looks like we currently make it non-trivial. But trivial-ABI needs to consider copy constructors as well as move constructors, which would undermine my case that it should be a subset of trivially-relocatability, at least in the fantasy world where there are correct types which default their move constructors but not their copy constructors or vice-versa.

So maybe you need a notion like "a class is BlahBlah if all of its direct members are BlahBlah, and either it is annotated [[maybe_trivially_relocatable]] or else it has no non-defaulted move or destroy operations." And then "a move-constructible, destructible class is trivially relocatable if it is BlahBlah, or if it is annotated [[trivially_relocatable]]." And then a class like DestroyBase can be "BlahBlah but not move-constructible," and if it's placed inside MoveBase, and MoveBase is both annotated and move-constructible, then MoveBase becomes trivially relocatable.

I'm completely comfortable with saying that MoveBase just isn't trivially-relocatable under maybe_trivially_relocatable attribute, and if you've somehow arranged for it to be, you need to use the stronger attribute. In practice types like this either won't exist or won't actually satisfy the requirements. That should allow you to avoid distinguishing between BlahBlah and trivially-relocatable. As long as the analysis jumps directly down to variant members instead of treating anonymous unions as formal subobjects, I don't think this will cause serious limitations or usability problems. Variant members are important as a special case only because anonymous unions can't really be fixed otherwise, and it's consistent with basically every other language rule around construction and destruction.

The benefit of my original "second-level" [[trivially_relocatable]] attribute is that it puts all the responsibility in a single very high-level place. optional is the thing that knows exactly when it's trivially relocatable (or at least can make a conservative guess, which might boil down to "I'm never trivially relocatable"), so optional is the thing that should get the attribute.

Yes, it's definitely unambiguous what happens with your stronger attribute.

If I get time today I'll try adding the boolean argument to the attribute, and do the libc++ patches that way for comparison.

Okay. Sorry for the delayed response, I had last week off.

[• Quuxplusone]

In D50119#1308869, @rjmccall wrote:

Hmm. I don't remember what we do in this case for trivial_abi (which does need to address it because it's possible to return types like DestroyBase). It looks like we currently make it non-trivial. But trivial-ABI needs to consider copy constructors as well as move constructors, which would undermine my case that it should be a subset of trivially-relocatability, at least in the fantasy world where there are correct types which default their move constructors but not their copy constructors or vice-versa.

Submitted for your consideration:

template<class T>
class HeapResource {
    std::unique_ptr<T> ptr_;
    HeapResource(const HeapResource& rhs) : ptr_(rhs.ptr_->clone()) {}  // not defaulted
    HeapResource(HeapResource&&) = default;  // defaulted
    ~HeapResource() = default;
};

This type is isomorphic to a real-world implementation of std::function. When you copy a HeapResource, you copy a T (which is observable); when you move a HeapResource, you do not touch T at all. Therefore copy-and-destroy is observably different from move-and-destroy. But (A) as a library vendor, I don't think I would care about clients who pathologically try to observe the difference; and (B) I don't think I grasp exactly how [[trivial_abi]] would care about this case either. (But remember: I still think of [[trivial_abi]] as completely orthogonal. You cut that debate short. ;) I would see no intrinsic difficulty with marking HeapResource as [[trivial_abi]], for example.)

So maybe you need a notion like "a class is BlahBlah if all of its direct members are BlahBlah, and either it is annotated [[maybe_trivially_relocatable]] or else it has no non-defaulted move or destroy operations." And then "a move-constructible, destructible class is trivially relocatable if it is BlahBlah, or if it is annotated [[trivially_relocatable]]." And then a class like DestroyBase can be "BlahBlah but not move-constructible," and if it's placed inside MoveBase, and MoveBase is both annotated and move-constructible, then MoveBase becomes trivially relocatable.

I'm completely comfortable with saying that MoveBase just isn't trivially-relocatable under maybe_trivially_relocatable attribute, and if you've somehow arranged for it to be, you need to use the stronger attribute.

To clarify: you'd be completely comfortable with the user's having the ability to "use the stronger attribute"? That is, there seems to be a reasonable argument in favor of the existence of the stronger attribute, even in the presence of the weaker attribute?

In practice types like this either won't exist or won't actually satisfy the requirements.

I think we probably agree on the nature of reality here, but I don't understand the way you phrased this sentence. I mean, DestroyBase and MoveBase absolutely do exist, in libc++'s implementation of optional. If you just mean that "in practice all such types will be private implementation details, and we'll never have to worry about the implications of these types' advertising themselves as trivially relocatable because they'll only ever be used in highly controlled circumstances where we can trust the programmer not to fall into any pits of their own making," then I agree, I think.

If I get time today I'll try adding the boolean argument to the attribute, and do the libc++ patches that way for comparison.

Okay. Sorry for the delayed response, I had last week off.

No worries. I didn't have last week off, and I still didn't actually get around to adding the boolean argument yet.

Speaking of the boolean argument... The usual usage will be something like [[trivially_relocatable(is_trivially_relocatable_v<allocator_type> && is_trivially_relocatable_v<pointer> && is_trivially_relocatable_v<size_type>)]], basically listing out the types of all the class's non-static data members. This has suddenly suggested to me that maybe the compiler could generate this kind of thing automatically... which we'd naturally spell [[trivially_relocatable(auto)]]! That is, maybe the right spelling for [[maybe_trivially_relocatable]] is [[trivially_relocatable(auto)]]!
...Or, on second thought, maybe not. That seems super prone to overuse and thus abuse, like, if someone blindly applied it to their codebase's equivalent of std::list. Yeah, I keep coming back to: the best way to avoid accidental knife injuries is to keep the knife sharp.

[• Quuxplusone]

Migrate this patch to the monorepo.
Apply @Mordante's improvements and test-suite fixes.
This patch now passes all tests (although it had to change the expected output of some of them).

[• Quuxplusone]

@rjmccall ping? any further thoughts on [[maybe_trivially_relocatable]], in light of the followup libc++ patches? (Those patches do not use [[maybe_trivially_relocatable]], although that may just be because I wrote them.)

How could one go about getting this patch into Clang?

Also, for those who haven't seen it, I gave a full-length talk on "trivially relocatable" at C++Now 2019: https://www.youtube.com/watch?v=SGdfPextuAU The talk compares my fully implemented Clang/libc++ solution https://wg21.link/p1144 to other practical solutions such as Folly, BSL, and EASTL, and to other paper solutions such as https://wg21.link/n4158 and https://wg21.link/p1029.

[rjmccall]

If the committee is actively looking into this problem and considering multiple alternatives, I don't see a particular need to accept your proposal into Clang in advance of the committee's decision. Arguably that would even be somewhat inappropriate, since it might be seen as an endorsement of your proposal over the alternatives, which I don't believe anyone from Clang has looked into. Letting the committee make a decision also addresses our disagreements about the language design and avoids introducing unnecessary divergence if the eventually-accepted design doesn't match your proposal.

Having a workable patch that you've taken advantage of in various projects should count as implementation experience for the committee's purposes.

[rjmccall]

If the committee *isn't* taking this up, they absolutely should, though.

[• Quuxplusone]

In D50119#1808616, @rjmccall wrote:

If the committee is actively looking into this problem and considering multiple alternatives, I don't see a particular need to accept your proposal into Clang in advance of the committee's decision. Arguably that would even be somewhat inappropriate, since it might be seen as an endorsement of your proposal over the alternatives, which I don't believe anyone from Clang has looked into. Letting the committee make a decision also addresses our disagreements about the language design and avoids introducing unnecessary divergence if the eventually-accepted design doesn't match your proposal.

Having a workable patch that you've taken advantage of in various projects should count as implementation experience for the committee's purposes.

If the committee *isn't* taking this up, they absolutely should, though.

I see the situation as exactly the opposite of what you just said. We cannot get implementation experience without an implementation. I would like Clang to be that implementation. But if Clang refuses to implement anything that is not Standard C++, then we have a chicken-and-egg problem: nobody can experiment with TR on real codebases until a compiler supports it. I would like Clang to be that compiler.

I don't plan to pursue P1144 any more in the ISO C++ Committee until someone has succeeded in implementing it in a compiler and letting people like Mark Elendt actually use it. You can say "ISO ought to take this up" all you want, but if no vendor is willing to implement the feature even with a pull request in hand, it's hardly fair to ask ISO to save you by standardizing it _before_ the implementation experience is in. They should be spending their time standardizing existing practice. That WG21 has been really really bad about standardizing vaporware lately is *not* a good trend, and I do not plan to encourage the trend.

Can you explain what is the distinction you draw between a new vendor-specific attribute like D70469 [[clang::acquire_handle]] or D70520 [[clang::export_name]] or D60455 [[clang::sycl_kernel]], and a new vendor-specific attribute like D50119 [[clang::trivially_relocatable]]? What's the secret sauce that permitted those extensions even as this one has stalled for years?

[rjmccall]

In D50119#1808727, @Quuxplusone wrote:

In D50119#1808616, @rjmccall wrote:

If the committee is actively looking into this problem and considering multiple alternatives, I don't see a particular need to accept your proposal into Clang in advance of the committee's decision. Arguably that would even be somewhat inappropriate, since it might be seen as an endorsement of your proposal over the alternatives, which I don't believe anyone from Clang has looked into. Letting the committee make a decision also addresses our disagreements about the language design and avoids introducing unnecessary divergence if the eventually-accepted design doesn't match your proposal.

Having a workable patch that you've taken advantage of in various projects should count as implementation experience for the committee's purposes.

If the committee *isn't* taking this up, they absolutely should, though.

I see the situation as exactly the opposite of what you just said. We cannot get implementation experience without an implementation. I would like Clang to be that implementation. But if Clang refuses to implement anything that is not Standard C++, then we have a chicken-and-egg problem: nobody can experiment with TR on real codebases until a compiler supports it. I would like Clang to be that compiler.

We have implementation experience: it's been implemented, and you have some experience using it. And LLVM/clang is a github project now, so you can easily make a fork somewhere with your patch applied, and people can build and use that compiler to get additional user experience. What you're asking now is for us to officially declare this to be a supported feature by putting it in our upcoming releases. I personally am not very fond of the proposed language design, so I'm not inclined to make that declaration. However, I don't speak for the entire clang project, and if consensus among other contributors is to take it, I won't block that. And of course we'll take it if the committee standardizes it.

Can you explain what is the distinction you draw between a new vendor-specific attribute like D70469 [[clang::acquire_handle]] or D70520 [[clang::export_name]] or D60455 [[clang::sycl_kernel]], and a new vendor-specific attribute like D50119 [[clang::trivially_relocatable]]? What's the secret sauce that permitted those extensions even as this one has stalled for years?

We are generally more conservative about taking features that are squarely about core language semantics and thus of direct interest to the language committee. The acquire/release attributes enable an interesting static analysis that it's hard to imagine would ever be standardized. export_name is a target-specific attribute. sycl_kernel is a standard part of the independently-standardized SYCL language extension. In contrast, this proposal describes a new core property of types, with complex interactions with the core language rules for implicit special members, and which clearly ought to be adopted throughout the standard library. And, as mentioned, you haven't sold us on the design.

compiler-explorer-llvm-commit.sh

+# This is the commit of LLVM that we're currently based on.
+git reset --hard 1fa19f68007cd126a04448093c171f40e556087e

docs/LanguageExtensions.rst

   of type ``totype`` can be assigned to from a value of type ``fromtype`` such
   that no non-trivial functions are called as part of that assignment.  This
   trait is required to implement the C++11 standard library.
 * ``__is_trivially_constructible(type, argtypes...)``: Determines whether a
   value of type ``type`` can be direct-initialized with arguments of types
   ``argtypes...`` such that no non-trivial functions are called as part of
   that initialization.  This trait is required to implement the C++11 standard
   library.
+* ``__is_trivially_relocatable`` (Clang): Determines whether moving an object
+  of type ``type``, and then destroying the source object, is functionally
+  equivalent to copying the underlying bytes and then dropping the source object
+  on the floor.
 * ``__is_destructible`` (MSVC 2013)
 * ``__is_nothrow_destructible`` (MSVC 2013)
 * ``__is_nothrow_assignable`` (MSVC 2013, clang)
 * ``__is_constructible`` (MSVC 2013, clang)
 * ``__is_nothrow_constructible`` (MSVC 2013, clang)
 * ``__is_assignable`` (MSVC 2015, clang)
 * ``__reference_binds_to_temporary(T, U)`` (Clang):  Determines whether a
   reference of type ``T`` bound to an expression of type ``U`` would bind to a

include/clang/AST/DeclCXX.h

struct DefinitionData {
     unsigned DeclaredNonTrivialSpecialMembers : 6;
 
     /// These bits keep track of the declared special members that are
     /// non-trivial for the purpose of calls.
     /// Only the bits corresponding to SMF_CopyConstructor,
     /// SMF_MoveConstructor, and SMF_Destructor are meaningful here.
     unsigned DeclaredNonTrivialSpecialMembersForCall : 6;
 
+    /// True when this class's bases and fields are all trivially relocatable,
+    /// and the class itself has a defaulted move constructor and a defaulted
+    /// destructor.
+    unsigned IsNaturallyTriviallyRelocatable : 1;
+
     /// True when this class has a destructor with no semantic effect.
     unsigned HasIrrelevantDestructor : 1;
 
     /// True when this class has at least one user-declared constexpr
     /// constructor which is neither the copy nor move constructor.
     unsigned HasConstexprNonCopyMoveConstructor : 1;
 
     /// True if this class has a (possibly implicit) defaulted default
bool hasNonTrivialDestructorForCall() const {
     return !(data().HasTrivialSpecialMembersForCall & SMF_Destructor);
   }
 
   void setHasTrivialSpecialMemberForCall() {
     data().HasTrivialSpecialMembersForCall =
         (SMF_CopyConstructor | SMF_MoveConstructor | SMF_Destructor);
   }
 
+  /// Determine whether this class is trivially relocatable
+  bool isTriviallyRelocatable() const {
+    return data().IsNaturallyTriviallyRelocatable ||
+           hasAttr<TriviallyRelocatableAttr>();
+  }
+
+  void setIsNotNaturallyTriviallyRelocatable() {
+    data().IsNaturallyTriviallyRelocatable = false;
+  }
+
   /// Determine whether declaring a const variable with this type is ok
   /// per core issue 253.
   bool allowConstDefaultInit() const {
     return !data().HasUninitializedFields ||
            !(data().HasDefaultedDefaultConstructor ||
              needsImplicitDefaultConstructor());
   }
 

include/clang/Basic/Attr.td

 }
 
 def ObjCRequiresPropertyDefs : InheritableAttr {
   let Spellings = [Clang<"objc_requires_property_definitions">];
   let Subjects = SubjectList<[ObjCInterface], ErrorDiag>;
   let Documentation = [Undocumented];
 }
 
+def TriviallyRelocatable : InheritableAttr {
+  let Spellings = [CXX11<"", "trivially_relocatable", 200809>,
+                   CXX11<"clang", "trivially_relocatable">];
+  let Subjects = SubjectList<[CXXRecord]>;
+  let Documentation = [TriviallyRelocatableDocs];
+  let LangOpts = [CPlusPlus];
+}
+
 def Unused : InheritableAttr {
   let Spellings = [CXX11<"", "maybe_unused", 201603>, GCC<"unused">,
                    C2x<"", "maybe_unused">];
   let Subjects = SubjectList<[Var, ObjCIvar, Type, Enum, EnumConstant, Label,
                               Field, ObjCMethod, FunctionLike]>;
   let Documentation = [WarnMaybeUnusedDocs];
 }
 

   let Subjects = SubjectList<[Record, Enum]>;
   // FIXME: Allow expressing logical AND for LangOpts. Our condition should be:
   // CPlusPlus && (MicrosoftExt || Borland)
   let LangOpts = [MicrosoftExt, Borland];
   let Documentation = [Undocumented];
 }
 
 def VectorSize : TypeAttr {
   let Spellings = [GCC<"vector_size">];
   let Args = [ExprArgument<"NumBytes">];
   let Documentation = [Undocumented];
 }
 
 def VecTypeHint : InheritableAttr {
   // Does not have a [[]] spelling because it is an OpenCL-related attribute.
   let Spellings = [GNU<"vec_type_hint">];
   let Args = [TypeArgument<"TypeHint">];

include/clang/Basic/AttrDocs.td

 - The class has a non-static data member whose type is non-trivial for the purposes of calls, which includes:
 
   - classes that are non-trivial for the purposes of calls
   - __weak-qualified types in Objective-C++
   - arrays of any of the above
   }];
 }
 
+def TriviallyRelocatableDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+A class type declared as ``[[trivially_relocatable]]`` warrants to
+the compiler that moving an object of that type, and then destroying the
+source object, is functionally equivalent to copying the underlying bytes
+and then dropping the source object on the floor.
+  }];
+}
+
 def MSInheritanceDocs : Documentation {
   let Category = DocCatType;
   let Heading = "__single_inhertiance, __multiple_inheritance, __virtual_inheritance";
   let Content = [{
 This collection of keywords is enabled under ``-fms-extensions`` and controls
 the pointer-to-member representation used on ``*-*-win32`` targets.
 
 The ``*-*-win32`` targets utilize a pointer-to-member representation which

include/clang/Basic/DiagnosticSemaKinds.td

 def err_base_specifier_attribute : Error<
   "%0 attribute cannot be applied to a base specifier">;
 def err_invalid_attribute_on_virtual_function : Error<
   "%0 attribute cannot be applied to virtual functions">;
 
 def ext_cannot_use_trivial_abi : ExtWarn<
   "'trivial_abi' cannot be applied to %0">, InGroup<IgnoredAttributes>;
 
+def err_trivially_relocatable_class_is_not_relocatable : Error<
+  "'trivially_relocatable' cannot be applied to "
+  "%select{struct|interface|union|class|enum}0 %1 because it is "
+  "not %select{move-constructible|destructible}2"
+  >;
+
 // Availability attribute
 def warn_availability_unknown_platform : Warning<
   "unknown platform %0 in availability macro">, InGroup<Availability>;
 def warn_availability_version_ordering : Warning<
   "feature cannot be %select{introduced|deprecated|obsoleted}0 in %1 version "
   "%2 before it was %select{introduced|deprecated|obsoleted}3 in version %4; "
   "attribute ignored">, InGroup<Availability>;
 def warn_mismatched_availability: Warning<

 def err_carries_dependency_param_not_function_decl : Error<
   "'[[carries_dependency]]' attribute only allowed on parameter in a function "
   "declaration or lambda">;
 def err_block_on_nonlocal : Error<
   "__block attribute not allowed, only allowed on local variables">;
 def err_block_on_vm : Error<
   "__block attribute not allowed on declaration with a variably modified type">;
 
+def err_attribute_missing_on_first_decl : Error<
+  "type %0 declared %1 after its first declaration">;
+def note_attribute_missing_first_decl : Note<
+  "declaration missing %0 attribute is here">;
+
 def err_vec_builtin_non_vector : Error<
  "first two arguments to %0 must be vectors">;
 def err_vec_builtin_incompatible_vector : Error<
   "first two arguments to %0 must have the same type">;
 def err_vsx_builtin_nonconstant_argument : Error<
   "argument %0 to %1 must be a 2-bit unsigned literal (i.e. 0, 1, 2 or 3)">;
 
 def err_shufflevector_nonconstant_argument : Error<
   "index for __builtin_shufflevector must be a constant integer">;
 def err_shufflevector_argument_too_large : Error<
   "index for __builtin_shufflevector must be less than the total number "
   "of vector elements">;
 
 def err_convertvector_non_vector : Error<
   "first argument to __builtin_convertvector must be a vector">;
 def err_convertvector_non_vector_type : Error<

include/clang/Basic/Features.def

 EXTENSION(cxx_reference_qualified_functions, LangOpts.CPlusPlus)
 EXTENSION(cxx_rvalue_references, LangOpts.CPlusPlus)
 EXTENSION(cxx_variadic_templates, LangOpts.CPlusPlus)
 // C++14 features supported by other languages as extensions.
 EXTENSION(cxx_binary_literals, true)
 EXTENSION(cxx_init_captures, LangOpts.CPlusPlus11)
 EXTENSION(cxx_variable_templates, LangOpts.CPlusPlus)
 // Miscellaneous language extensions
+EXTENSION(trivially_relocatable, LangOpts.CPlusPlus11)
 EXTENSION(overloadable_unmarked, true)
 
 #undef EXTENSION
 #undef FEATURE

include/clang/Basic/TokenKinds.def

 TYPE_TRAIT_1(__is_union, IsUnion, KEYCXX)
 TYPE_TRAIT_1(__has_unique_object_representations,
              HasUniqueObjectRepresentations, KEYCXX)
 
 // Clang-only C++ Type Traits
 TYPE_TRAIT_N(__is_trivially_constructible, IsTriviallyConstructible, KEYCXX)
 TYPE_TRAIT_1(__is_trivially_copyable, IsTriviallyCopyable, KEYCXX)
 TYPE_TRAIT_2(__is_trivially_assignable, IsTriviallyAssignable, KEYCXX)
+TYPE_TRAIT_1(__is_trivially_relocatable, IsTriviallyRelocatable, KEYCXX)
 TYPE_TRAIT_2(__reference_binds_to_temporary, ReferenceBindsToTemporary, KEYCXX)
 KEYWORD(__underlying_type           , KEYCXX)
 
 // Embarcadero Expression Traits
 KEYWORD(__is_lvalue_expr            , KEYCXX)
 KEYWORD(__is_rvalue_expr            , KEYCXX)
 
 // Embarcadero Unary Type Traits

include/clang/Basic/TypeTraits.h

enum TypeTrait {
     UTT_IsRvalueReference,
     UTT_IsScalar,
     UTT_IsSealed,
     UTT_IsSigned,
     UTT_IsStandardLayout,
     UTT_IsTrivial,
     UTT_IsTriviallyCopyable,
     UTT_IsTriviallyDestructible,
+    UTT_IsTriviallyRelocatable,
     UTT_IsUnion,
     UTT_IsUnsigned,
     UTT_IsVoid,
     UTT_IsVolatile,
     UTT_HasUniqueObjectRepresentations,
     UTT_Last = UTT_HasUniqueObjectRepresentations,
     BTT_IsBaseOf,
     BTT_IsConvertible,

include/clang/Sema/Sema.h

   ExprResult ActOnArraySubscriptExpr(Scope *S, Expr *Base, SourceLocation LLoc,
                                      Expr *Idx, SourceLocation RLoc);
   ExprResult CreateBuiltinArraySubscriptExpr(Expr *Base, SourceLocation LLoc,
                                              Expr *Idx, SourceLocation RLoc);
   ExprResult ActOnOMPArraySectionExpr(Expr *Base, SourceLocation LBLoc,
                                       Expr *LowerBound, SourceLocation ColonLoc,
                                       Expr *Length, SourceLocation RBLoc);
 
+  bool IsTriviallyRelocatableType(QualType QT) const;
+
   // This struct is for use by ActOnMemberAccess to allow
   // BuildMemberReferenceExpr to be able to reinvoke ActOnMemberAccess after
   // changing the access operator from a '.' to a '->' (to see if that is the
   // change needed to fix an error about an unknown member, e.g. when the class
   // defines a custom operator->).
   struct ActOnMemberAccessExtraArgs {
     Scope *S;
     UnqualifiedId &Id;

lib/AST/ASTImporter.cpp

     ToData.DefaultedCopyConstructorIsDeleted
       = FromData.DefaultedCopyConstructorIsDeleted;
     ToData.DefaultedMoveConstructorIsDeleted
       = FromData.DefaultedMoveConstructorIsDeleted;
     ToData.DefaultedMoveAssignmentIsDeleted
       = FromData.DefaultedMoveAssignmentIsDeleted;
     ToData.DefaultedDestructorIsDeleted = FromData.DefaultedDestructorIsDeleted;
     ToData.HasTrivialSpecialMembers = FromData.HasTrivialSpecialMembers;
+    ToData.IsNaturallyTriviallyRelocatable
+      = FromData.IsNaturallyTriviallyRelocatable;
     ToData.HasIrrelevantDestructor = FromData.HasIrrelevantDestructor;
     ToData.HasConstexprNonCopyMoveConstructor
       = FromData.HasConstexprNonCopyMoveConstructor;
     ToData.HasDefaultedDefaultConstructor
       = FromData.HasDefaultedDefaultConstructor;
     ToData.DefaultedDefaultConstructorIsConstexpr
       = FromData.DefaultedDefaultConstructorIsConstexpr;
     ToData.HasConstexprDefaultConstructor

lib/AST/DeclCXX.cpp

: UserDeclaredConstructor(false), UserDeclaredSpecialMembers(0),
       NeedOverloadResolutionForMoveAssignment(false),
       NeedOverloadResolutionForDestructor(false),
       DefaultedCopyConstructorIsDeleted(false),
       DefaultedMoveConstructorIsDeleted(false),
       DefaultedMoveAssignmentIsDeleted(false),
       DefaultedDestructorIsDeleted(false), HasTrivialSpecialMembers(SMF_All),
       HasTrivialSpecialMembersForCall(SMF_All),
       DeclaredNonTrivialSpecialMembers(0),
-      DeclaredNonTrivialSpecialMembersForCall(0), HasIrrelevantDestructor(true),
+      DeclaredNonTrivialSpecialMembersForCall(0),
+      IsNaturallyTriviallyRelocatable(true), HasIrrelevantDestructor(true),
       HasConstexprNonCopyMoveConstructor(false),
       HasDefaultedDefaultConstructor(false),
       DefaultedDefaultConstructorIsConstexpr(true),
       HasConstexprDefaultConstructor(false),
       HasNonLiteralTypeFieldsOrBases(false), ComputedVisibleConversions(false),
       UserProvidedDefaultConstructor(false), DeclaredSpecialMembers(0),
       ImplicitCopyConstructorCanHaveConstParamForVBase(true),
       ImplicitCopyConstructorCanHaveConstParamForNonVBase(true),
if (!BaseClassDecl->isStandardLayout())
       data().IsStandardLayout = false;
     if (!BaseClassDecl->isCXX11StandardLayout())
       data().IsCXX11StandardLayout = false;
 
     // Record if this base is the first non-literal field or base.
     if (!hasNonLiteralTypeFieldsOrBases() && !BaseType->isLiteralType(C))
       data().HasNonLiteralTypeFieldsOrBases = true;
 
+    if (Base->isVirtual() || !BaseClassDecl->isTriviallyRelocatable())
+      setIsNotNaturallyTriviallyRelocatable();
+
     // Now go through all virtual bases of this base and add them.
     for (const auto &VBase : BaseClassDecl->vbases()) {
       // Add this base if it's not already in the list.
       if (SeenVBaseTypes.insert(C.getCanonicalType(VBase.getType())).second) {
         VBases.push_back(&VBase);
 
         // C++11 [class.copy]p8:
         //   The implicitly-declared copy constructor for a class X will have

lib/Parse/ParseDeclCXX.cpp

 
 static bool IsBuiltInOrStandardCXX11Attribute(IdentifierInfo *AttrName,
                                               IdentifierInfo *ScopeName) {
   switch (ParsedAttr::getKind(AttrName, ScopeName, ParsedAttr::AS_CXX11)) {
   case ParsedAttr::AT_CarriesDependency:
   case ParsedAttr::AT_Deprecated:
   case ParsedAttr::AT_FallThrough:
   case ParsedAttr::AT_CXX11NoReturn:
+  case ParsedAttr::AT_TriviallyRelocatable:
     return true;
   case ParsedAttr::AT_WarnUnusedResult:
     return !ScopeName && AttrName->getName().equals("nodiscard");
   case ParsedAttr::AT_Unused:
     return !ScopeName && AttrName->getName().equals("maybe_unused");
   default:
     return false;
   }

lib/Sema/SemaDecl.cpp

     ProcessDeclAttributeList(S, Record, Attrs);
 
     // We may have deferred checking for a deleted destructor. Check now.
     if (CXXRecordDecl *CXXRecord = dyn_cast<CXXRecordDecl>(Record)) {
       auto *Dtor = CXXRecord->getDestructor();
       if (Dtor && Dtor->isImplicit() &&
           ShouldDeleteSpecialMember(Dtor, CXXDestructor)) {
         CXXRecord->setImplicitDestructorIsDeleted();
+        CXXRecord->setIsNotNaturallyTriviallyRelocatable();
         SetDeclDeleted(Dtor, CXXRecord->getLocation());
       }
     }
 
     if (Record->hasAttrs()) {
       CheckAlignasUnderalignment(Record);
 
       if (const MSInheritanceAttr *IA = Record->getAttr<MSInheritanceAttr>())

lib/Sema/SemaDeclAttr.cpp

     return;
   }
 
   D->addAttr(::new (S.Context)
                  LayoutVersionAttr(AL.getRange(), S.Context, Version,
                                    AL.getAttributeSpellingListIndex()));
 }
 
+template<class AttrType>
+static void checkAttributeNotOnFirstDecl(Sema &S, Decl *D, const ParsedAttr &AL) {
+  Decl *FirstD = D->getCanonicalDecl();
+  if (FirstD != D && !FirstD->hasAttr<AttrType>()) {
+    NamedDecl *ND = dyn_cast<NamedDecl>(D);
+    S.Diag(AL.getLoc(), diag::err_attribute_missing_on_first_decl)
+      << (ND ? ND->getDeclName().getAsString() : "<unnamed>") << AL.getName();
+    S.Diag(FirstD->getLocation(), diag::note_attribute_missing_first_decl)
+      << AL.getName()
+      << FirstD->getSourceRange();
+  }
+}
+
+static void handleTriviallyRelocatableAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  checkAttributeNotOnFirstDecl<TriviallyRelocatableAttr>(S, D, AL);
+  handleSimpleAttribute<TriviallyRelocatableAttr>(S, D, AL);
+}
+
 DLLImportAttr *Sema::mergeDLLImportAttr(Decl *D, SourceRange Range,
                                         unsigned AttrSpellingListIndex) {
   if (D->hasAttr<DLLExportAttr>()) {
     Diag(Range.getBegin(), diag::warn_attribute_ignored) << "'dllimport'";
     return nullptr;
   }
 
   if (D->hasAttr<DLLImportAttr>())

     handleSimpleAttribute<EmptyBasesAttr>(S, D, AL);
     break;
   case ParsedAttr::AT_LayoutVersion:
     handleLayoutVersion(S, D, AL);
     break;
   case ParsedAttr::AT_TrivialABI:
     handleSimpleAttribute<TrivialABIAttr>(S, D, AL);
     break;
+  case ParsedAttr::AT_TriviallyRelocatable:
+    handleTriviallyRelocatableAttr(S, D, AL);
+    break;
   case ParsedAttr::AT_MSNoVTable:
     handleSimpleAttribute<MSNoVTableAttr>(S, D, AL);
     break;
   case ParsedAttr::AT_MSStruct:
     handleSimpleAttribute<MSStructAttr>(S, D, AL);
     break;
   case ParsedAttr::AT_Uuid:
     handleUuidAttr(S, D, AL);

lib/Sema/SemaDeclCXX.cpp

       // Set triviality for the purpose of calls if this is a user-provided
       // copy/move constructor or destructor.
       if ((CSM == CXXCopyConstructor || CSM == CXXMoveConstructor ||
            CSM == CXXDestructor) && M->isUserProvided()) {
         M->setTrivialForCall(HasTrivialABI);
         Record->setTrivialForCallFlags(M);
       }
 
+      // A move-constructible, destructible object type T is a
+      // trivially relocatable type if it ...
+      if ((CSM == CXXMoveConstructor || CSM == CXXDestructor) &&
+          (M->isUserProvided() || M->isDeleted())) {
+        // - has either a defaulted, non-deleted move constructor or no
+        // move constructor and a defaulted, non-deleted copy constructor,
+        // - has a defaulted, non-deleted destructor,
+        Record->setIsNotNaturallyTriviallyRelocatable();
+      } else if (CSM == CXXDestructor && M->isVirtual()) {
+        // - either is final, or has a final destructor,
+        // or has a non-virtual destructor ...
+        if (!M->hasAttr<FinalAttr>() && !Record->hasAttr<FinalAttr>())
+          Record->setIsNotNaturallyTriviallyRelocatable();
+      }
+
       if (!M->isInvalidDecl() && M->isExplicitlyDefaulted() &&
           M->hasAttr<DLLExportAttr>()) {
         if (getLangOpts().isCompatibleWithMSVC(LangOptions::MSVC2015) &&
             M->isTrivial() &&
             (CSM == CXXDefaultConstructor || CSM == CXXCopyConstructor ||
              CSM == CXXDestructor))
           M->dropAttr<DLLExportAttr>();
 
         if (M->hasAttr<DLLExportAttr>()) {
           DefineImplicitSpecialMember(*this, M, M->getLocation());
           ActOnFinishInlineFunctionDef(M);
         }
       }
     }
   }
 
+  for (auto *F : Record->fields()) {
+    if (F->isMutable()) {
+      Record->setIsNotNaturallyTriviallyRelocatable();
+      break;
+    }
+
+    QualType FT = F->getType();
+    if (!FT->isReferenceType() && !IsTriviallyRelocatableType(FT)) {
+      Record->setIsNotNaturallyTriviallyRelocatable();
+      break;
+    }
+  }
+
   if (HasMethodWithOverrideControl &&
       HasOverridingMethodWithoutOverrideControl) {
     // At least one method has the 'override' control declared.
     // Diagnose all other overridden methods which do not have 'override' specified on them.
     for (auto *M : Record->methods())
       DiagnoseAbsenceOfOverrideControl(M);
   }
 

   else if (Record->hasNonTrivialDestructor())
     Record->setParamDestroyedInCallee(CanPass);
 
   if (getLangOpts().ForceEmitVTables) {
     // If we want to emit all the vtables, we need to mark it as used.  This
     // is especially required for cases like vtable assumption loads.
     MarkVTableUsed(Record->getInnerLocStart(), Record);
   }
+
+  if (getLangOpts().CPlusPlus11 && Record->isTriviallyRelocatable()) {
+    if (Record->getDefinition() && !Record->isDependentContext() &&
+        !Record->isBeingDefined()) {
+      if (!Record->needsImplicitMoveConstructor()) {
+        // Check that the constructor used for move-construction is defaulted
+        // and non-deleted.
+        SpecialMemberOverloadResult SMOR = LookupSpecialMember(
+            Record, CXXMoveConstructor, false, false, false, false, false);
+        if (SMOR.getKind() != SpecialMemberOverloadResult::Success ||
+            !SMOR.getMethod()->isDefaulted()) {
+          Record->setIsNotNaturallyTriviallyRelocatable();
+        }
+      }
+    }
+  }
+
+  if (getLangOpts().CPlusPlus11 &&
+      Record->hasAttr<TriviallyRelocatableAttr>() &&
+      !isTemplateInstantiation(Record->getTemplateSpecializationKind())) {
+    if (Record->getDefinition() && !Record->isDependentContext() &&
+        !Record->isBeingDefined()) {
+      // Check that the destructor is non-deleted.
+      SpecialMemberOverloadResult SMOR = LookupSpecialMember(
+          Record, CXXDestructor, false, false, false, false, false);
+      if (SMOR.getKind() != SpecialMemberOverloadResult::Success) {
+        Diag(Record->getLocation(),
+             diag::err_trivially_relocatable_class_is_not_relocatable)
+            << Record->getCanonicalDecl()->getTagKind()
+            << Context.getRecordType(Record) << true;
+        Record->dropAttr<TriviallyRelocatableAttr>();
+      } else if (Record->needsImplicitMoveConstructor() &&
+                 Record->defaultedMoveConstructorIsDeleted()) {
+        Diag(Record->getLocation(),
+             diag::err_trivially_relocatable_class_is_not_relocatable)
+            << Record->getCanonicalDecl()->getTagKind()
+            << Context.getRecordType(Record) << false;
+        Record->dropAttr<TriviallyRelocatableAttr>();
+      } else {
+        // Check that the constructor used for move-construction is non-deleted.
+        SMOR = LookupSpecialMember(Record, CXXMoveConstructor, false, false,
+                                   false, false, false);
+        if (SMOR.getKind() != SpecialMemberOverloadResult::Success) {
+          Diag(Record->getLocation(),
+               diag::err_trivially_relocatable_class_is_not_relocatable)
+              << Record->getCanonicalDecl()->getTagKind()
+              << Context.getRecordType(Record) << false;
+          Record->dropAttr<TriviallyRelocatableAttr>();
+        }
+      }
+    }
+  }
 }
 
 /// Look up the special member function that would be called by a special
 /// member function for a subobject of class type.
 ///
 /// \param Class The class type of the subobject.
 /// \param CSM The kind of special member function.
 /// \param FieldQuals If the subobject is a field, its cv-qualifiers.

   if (First) {
     //  -- it is implicitly considered to be constexpr if the implicit
     //     definition would be,
     MD->setConstexpr(Constexpr);
 
     //  -- it is implicitly considered to have the same exception-specification
     //     as if it had been implicitly declared,
     FunctionProtoType::ExtProtoInfo EPI = Type->getExtProtoInfo();
     EPI.ExceptionSpec.Type = EST_Unevaluated;
     EPI.ExceptionSpec.SourceDecl = MD;
     MD->setType(Context.getFunctionType(ReturnType,
                                         llvm::makeArrayRef(&ArgType,
                                                            ExpectedParams),
                                         EPI));
   }
 
   if (ShouldDeleteSpecialMember(MD, CSM)) {

   // Note that we have declared this constructor.
   ++ASTContext::NumImplicitMoveConstructorsDeclared;
 
   Scope *S = getScopeForContext(ClassDecl);
   CheckImplicitSpecialMemberDeclaration(S, MoveConstructor);
 
   if (ShouldDeleteSpecialMember(MoveConstructor, CXXMoveConstructor)) {
     ClassDecl->setImplicitMoveConstructorIsDeleted();
+    ClassDecl->setIsNotNaturallyTriviallyRelocatable();
     SetDeclDeleted(MoveConstructor, ClassLoc);
   }
 
   if (S)
     PushOnScopeChains(MoveConstructor, S, false);
   ClassDecl->addDecl(MoveConstructor);
 
   return MoveConstructor;

lib/Sema/SemaExprCXX.cpp

     ArgTy = QualType(ArgTy->getBaseElementTypeUnsafe(), 0);
     LLVM_FALLTHROUGH;
 
   // C++1z [meta.unary.prop]:
   //   T shall be a complete type, cv void, or an array of unknown bound.
   case UTT_IsDestructible:
   case UTT_IsNothrowDestructible:
   case UTT_IsTriviallyDestructible:
+  case UTT_IsTriviallyRelocatable:
   case UTT_HasUniqueObjectRepresentations:
     if (ArgTy->isIncompleteArrayType() || ArgTy->isVoidType())
       return true;
 
     return !S.RequireCompleteType(
         Loc, ArgTy, diag::err_incomplete_type_used_in_type_trait_expr);
   }
 }

         const FunctionProtoType *CPT =
             Destructor->getType()->getAs<FunctionProtoType>();
         CPT = Self.ResolveExceptionSpec(KeyLoc, CPT);
         if (!CPT || !CPT->isNothrow())
           return false;
       }
     }
     return true;
-
+  case UTT_IsTriviallyRelocatable:
+    return Self.IsTriviallyRelocatableType(T);
   case UTT_HasTrivialDestructor:
     // http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html
     //   If __is_pod (type) is true or type is a reference type
     //   then the trait is true, else if type is a cv class or union
     //   type (or array thereof) with a trivial destructor
     //   ([class.dtor]) then the trait is true, else it is
     //   false.
     if (T.isPODType(C) || T->isReferenceType())

     //   Returns True if and only if T is a complete type at the point of the
     //   function call.
     return !T->isIncompleteType();
   case UTT_HasUniqueObjectRepresentations:
     return C.hasUniqueObjectRepresentations(T);
   }
 }
 
+bool Sema::IsTriviallyRelocatableType(QualType QT) const {
+  QualType T = Context.getBaseElementType(QT);
+  if (T->isIncompleteType())
+    return false;
+  if (CXXRecordDecl *RD = T->getAsCXXRecordDecl()) {
+    return RD->isTriviallyRelocatable();
+  } else {
+    // Non-class types are always both move-constructible and destructible,
+    // so just check whether a non-class type is trivially copyable.
+    return T.isTriviallyCopyableType(Context);
+  }
+}
+
 static bool EvaluateBinaryTypeTrait(Sema &Self, TypeTrait BTT, QualType LhsT,
                                     QualType RhsT, SourceLocation KeyLoc);
 
 static bool evaluateTypeTrait(Sema &S, TypeTrait Kind, SourceLocation KWLoc,
                               ArrayRef<TypeSourceInfo *> Args,
                               SourceLocation RParenLoc) {
   if (Kind <= UTT_Last)
     return EvaluateUnaryTypeTrait(S, Kind, KWLoc, Args[0]->getType());

lib/Serialization/ASTReaderDecl.cpp

   Data.DefaultedCopyConstructorIsDeleted = Record.readInt();
   Data.DefaultedMoveConstructorIsDeleted = Record.readInt();
   Data.DefaultedMoveAssignmentIsDeleted = Record.readInt();
   Data.DefaultedDestructorIsDeleted = Record.readInt();
   Data.HasTrivialSpecialMembers = Record.readInt();
   Data.HasTrivialSpecialMembersForCall = Record.readInt();
   Data.DeclaredNonTrivialSpecialMembers = Record.readInt();
   Data.DeclaredNonTrivialSpecialMembersForCall = Record.readInt();
+  Data.IsNaturallyTriviallyRelocatable = Record.readInt();
   Data.HasIrrelevantDestructor = Record.readInt();
   Data.HasConstexprNonCopyMoveConstructor = Record.readInt();
   Data.HasDefaultedDefaultConstructor = Record.readInt();
   Data.DefaultedDefaultConstructorIsConstexpr = Record.readInt();
   Data.HasConstexprDefaultConstructor = Record.readInt();
   Data.HasNonLiteralTypeFieldsOrBases = Record.readInt();
   Data.ComputedVisibleConversions = Record.readInt();
   Data.UserProvidedDefaultConstructor = Record.readInt();

   MATCH_FIELD(DefaultedCopyConstructorIsDeleted)
   MATCH_FIELD(DefaultedMoveConstructorIsDeleted)
   MATCH_FIELD(DefaultedMoveAssignmentIsDeleted)
   MATCH_FIELD(DefaultedDestructorIsDeleted)
   OR_FIELD(HasTrivialSpecialMembers)
   OR_FIELD(HasTrivialSpecialMembersForCall)
   OR_FIELD(DeclaredNonTrivialSpecialMembers)
   OR_FIELD(DeclaredNonTrivialSpecialMembersForCall)
+  MATCH_FIELD(IsNaturallyTriviallyRelocatable)
   MATCH_FIELD(HasIrrelevantDestructor)
   OR_FIELD(HasConstexprNonCopyMoveConstructor)
   OR_FIELD(HasDefaultedDefaultConstructor)
   MATCH_FIELD(DefaultedDefaultConstructorIsConstexpr)
   OR_FIELD(HasConstexprDefaultConstructor)
   MATCH_FIELD(HasNonLiteralTypeFieldsOrBases)
   // ComputedVisibleConversions is handled below.
   MATCH_FIELD(UserProvidedDefaultConstructor)

lib/Serialization/ASTWriter.cpp

   Record->push_back(Data.DefaultedCopyConstructorIsDeleted);
   Record->push_back(Data.DefaultedMoveConstructorIsDeleted);
   Record->push_back(Data.DefaultedMoveAssignmentIsDeleted);
   Record->push_back(Data.DefaultedDestructorIsDeleted);
   Record->push_back(Data.HasTrivialSpecialMembers);
   Record->push_back(Data.HasTrivialSpecialMembersForCall);
   Record->push_back(Data.DeclaredNonTrivialSpecialMembers);
   Record->push_back(Data.DeclaredNonTrivialSpecialMembersForCall);
+  Record->push_back(Data.IsNaturallyTriviallyRelocatable);
   Record->push_back(Data.HasIrrelevantDestructor);
   Record->push_back(Data.HasConstexprNonCopyMoveConstructor);
   Record->push_back(Data.HasDefaultedDefaultConstructor);
   Record->push_back(Data.DefaultedDefaultConstructorIsConstexpr);
   Record->push_back(Data.HasConstexprDefaultConstructor);
   Record->push_back(Data.HasNonLiteralTypeFieldsOrBases);
   Record->push_back(Data.ComputedVisibleConversions);
   Record->push_back(Data.UserProvidedDefaultConstructor);

test/Lexer/has_extension_cxx.cpp

 int has_variable_templates();
 #endif
 
 // CHECK-NOT: has_init_captures
 // CHECK11: has_init_captures
 #if __has_extension(cxx_init_captures)
 int has_init_captures();
 #endif
+
+// CHECK-NOT: has_trivially_relocatable
+// CHECK11: has_trivially_relocatable
+#if __has_extension(trivially_relocatable)
+int has_trivially_relocatable();
+#endif

test/Misc/pragma-attribute-supported-attributes-list.test

 // RUN: clang-tblgen -gen-clang-test-pragma-attribute-supported-attributes -I%src_include_dir %src_include_dir/clang/Basic/Attr.td -o - | FileCheck %s
 
 // The number of supported attributes should never go down!
 
-// CHECK: #pragma clang attribute supports 72 attributes:
+// CHECK: #pragma clang attribute supports 73 attributes:
 // CHECK-NEXT: AMDGPUFlatWorkGroupSize (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUNumSGPR (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUNumVGPR (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUWavesPerEU (SubjectMatchRule_function)
 // CHECK-NEXT: AVRSignal (SubjectMatchRule_function)
 // CHECK-NEXT: AbiTag (SubjectMatchRule_record_not_is_union, SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_namespace)
 // CHECK-NEXT: AlignValue (SubjectMatchRule_variable, SubjectMatchRule_type_alias)
 // CHECK-NEXT: AllocSize (SubjectMatchRule_function)

 // CHECK-NEXT: SetTypestate (SubjectMatchRule_function_is_member)
 // CHECK-NEXT: SwiftContext (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: SwiftErrorResult (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: SwiftIndirectResult (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: TLSModel (SubjectMatchRule_variable_is_thread_local)
 // CHECK-NEXT: Target (SubjectMatchRule_function)
 // CHECK-NEXT: TestTypestate (SubjectMatchRule_function_is_member)
 // CHECK-NEXT: TrivialABI (SubjectMatchRule_record)
+// CHECK-NEXT: TriviallyRelocatable (SubjectMatchRule_record)
 // CHECK-NEXT: WarnUnusedResult (SubjectMatchRule_objc_method, SubjectMatchRule_enum, SubjectMatchRule_record, SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: XRayInstrument (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: XRayLogArgs (SubjectMatchRule_function, SubjectMatchRule_objc_method)

test/SemaCXX/trivially-relocatable.cpp

+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++11
+// expected-diagnostics
+
+static_assert(__has_extension(trivially_relocatable), "");
+
+// It shall appear at most once in each attribute-list
+// and no attribute-argument-clause shall be present.
+
+struct [[trivially_relocatable, trivially_relocatable]] B1 {};
+// expected-error@-1{{attribute 'trivially_relocatable' cannot appear multiple times in an attribute specifier}}
+
+struct [[trivially_relocatable]] [[trivially_relocatable]] B2 {}; // should really be an error
+
+struct [[trivially_relocatable(42)]] B3 {};
+// expected-error@-1{{attribute 'trivially_relocatable' cannot have an argument list}}
+
+
+//   The first declaration of a type shall specify the
+//   trivially_relocatable attribute if any declaration of that
+//   type specifies the trivially_relocatable attribute.
+
+struct [[trivially_relocatable]] A1 {};  // ok
+struct [[trivially_relocatable]] A1;
+
+struct [[trivially_relocatable]] A2;  // ok
+struct [[trivially_relocatable]] A2 {};
+
+struct [[trivially_relocatable]] A3 {};  // ok
+struct A3;
+
+struct [[trivially_relocatable]] A4;  // ok
+struct A4 {};
+
+struct A5 {};
+struct [[trivially_relocatable]] A5;
+// expected-error@-1{{type A5 declared 'trivially_relocatable' after its first declaration}}
+// expected-note@-3{{declaration missing 'trivially_relocatable' attribute is here}}
+// expected-warning@-3{{attribute declaration must precede definition}}
+// expected-note@-5{{previous definition is here}}
+
+struct A6;
+struct [[trivially_relocatable]] A6 {};
+// expected-error@-1{{type A6 declared 'trivially_relocatable' after its first declaration}}
+// expected-note@-3{{declaration missing 'trivially_relocatable' attribute is here}}
+
+
+// If a type T is declared with the trivially_relocatable attribute, and T is either
+// not move-constructible or not destructible, the program is ill-formed.
+
+struct NonDestructible {
+    NonDestructible(const NonDestructible&) = default;
+    NonDestructible(NonDestructible&&) = default;
+    ~NonDestructible() = delete;
+};
+struct NonCopyConstructible {
+    NonCopyConstructible(const NonCopyConstructible&) = delete;
+};
+struct NonMoveConstructible {
+    NonMoveConstructible(const NonMoveConstructible&) = default;
+    NonMoveConstructible(NonMoveConstructible&&) = delete;
+};
+static_assert(!__is_trivially_relocatable(NonDestructible), "");
+static_assert(!__is_trivially_relocatable(NonCopyConstructible), "");
+static_assert(!__is_constructible(NonCopyConstructible, NonCopyConstructible&&), "");
+static_assert(!__is_trivially_relocatable(NonMoveConstructible), "");
+static_assert(!__is_constructible(NonMoveConstructible, NonMoveConstructible&&), "");
+
+struct [[trivially_relocatable]] D1 { ~D1() = delete; };
+// expected-error@-1{{cannot be applied to struct 'D1' because it is not destructible}}
+
+struct [[trivially_relocatable]] D2 : private NonDestructible { };
+// expected-error@-1{{cannot be applied to struct 'D2' because it is not destructible}}
+
+struct [[trivially_relocatable]] D3 { D3(const D3&) = delete; };
+// expected-error@-1{{cannot be applied to struct 'D3' because it is not move-constructible}}
+
+struct [[trivially_relocatable]] D4 { D4(const D4&) = default; D4(D4&&) = delete; };
+// expected-error@-1{{cannot be applied to struct 'D4' because it is not move-constructible}}
+
+struct [[trivially_relocatable]] D5 : private NonCopyConstructible { };
+// expected-error@-1{{cannot be applied to struct 'D5' because it is not move-constructible}}
+static_assert(!__is_constructible(D5, D5&&), "");
+
+struct [[trivially_relocatable]] D6 : private NonMoveConstructible { D6(D6&&) = default; };
+// expected-error@-1{{cannot be applied to struct 'D6' because it is not move-constructible}}
+
+template<class T>
+struct [[trivially_relocatable]] DT1 : private T { };  // ok
+
+struct D7 {
+    DT1<NonDestructible> m;
+};
+
+class [[trivially_relocatable]] D8 {
+    DT1<NonDestructible> m;
+};
+// expected-error@-3{{cannot be applied to class 'D8' because it is not destructible}}
+
+
+// Now test specific types for trivial relocatability.
+
+static_assert(__is_trivially_relocatable(char), "");
+static_assert(__is_trivially_relocatable(int), "");
+static_assert(__is_trivially_relocatable(int*), "");
+static_assert(!__is_trivially_relocatable(int&), "");
+static_assert(__is_trivially_relocatable(float), "");
+static_assert(__is_trivially_relocatable(double), "");
+static_assert(!__is_trivially_relocatable(void), "");
+static_assert(__is_trivially_relocatable(char[1]), "");
+static_assert(__is_trivially_relocatable(char[]), "");
+
+static_assert(__is_trivially_relocatable(const int), "");
+static_assert(__is_trivially_relocatable(volatile int), "");
+static_assert(!__is_trivially_relocatable(const int&), "");
+static_assert(!__is_trivially_relocatable(volatile int&), "");
+
+struct C1 { int x; }; static_assert(__is_trivially_relocatable(C1), "");
+struct C2 { const int x; }; static_assert(__is_trivially_relocatable(C2), "");
+struct C3 { volatile int x; }; static_assert(__is_trivially_relocatable(C3), "");
+struct C4 { int *x; }; static_assert(__is_trivially_relocatable(C4), "");
+struct C5 { const int *x; }; static_assert(__is_trivially_relocatable(C5), "");
+struct C6 { volatile int *x; }; static_assert(__is_trivially_relocatable(C6), "");
+struct C7 { int& x; }; static_assert(__is_trivially_relocatable(C7), "");
+struct C8 { const int& x; }; static_assert(__is_trivially_relocatable(C8), "");
+struct C9 { volatile int& x; }; static_assert(__is_trivially_relocatable(C9), "");
+
+enum E { x = 1, y = 2 };
+static_assert(__is_trivially_relocatable(E), "");
+static_assert(__is_trivially_relocatable(E[1]), "");
+
+struct T1 {};
+static_assert(__is_trivially_relocatable(T1), "");
+
+struct T2 { int x; E y; int *z; };
+static_assert(__is_trivially_relocatable(T2), "");
+
+struct T3 { int x; T3(T3&&) = default; };
+static_assert(__is_trivially_relocatable(T3), "");
+
+struct T4 { int x; ~T4() = default; };
+static_assert(__is_trivially_relocatable(T4), "trivially copy-constructible, and no move constructor");
+
+struct T4a { T4 a; };
+static_assert(__is_trivially_relocatable(T4a), "trivially copy-constructible, and no move constructor");
+
+
+struct VD {
+    VD(const VD&) = default;
+    VD(VD&&) = default;
+    virtual ~VD() = default;
+};
+void relocate_example(VD&& src) {
+    VD dst(static_cast<VD&&>(src));  // this DEFINITELY calls the trivial move-constructor
+    src.~VD();  // this MAY virtually dispatch to a non-trivial destructor
+}
+static_assert(!__is_trivially_relocatable(VD), "");
+
+
+struct VD2 final {
+    VD2(const VD2&) = default;
+    VD2(VD2&&) = default;
+    virtual ~VD2() = default;
+};
+void relocate_example(VD2&& src) {
+    VD2 dst(static_cast<VD2&&>(src));  // this DEFINITELY calls the trivial move-constructor
+    src.~VD2();  // because "final", this CANNOT virtually dispatch to a non-trivial destructor
+}
+static_assert(__is_trivially_relocatable(VD2), "");
+
+
+struct VD3 {
+    VD3(const VD3&) = default;
+    VD3(VD3&&) = default;
+    virtual ~VD3() final = default;
+};
+void relocate_example(VD3&& src) {
+    VD3 dst(static_cast<VD3&&>(src));  // this DEFINITELY calls the trivial move-constructor
+    src.~VD3();  // because "final", this CANNOT virtually dispatch to a non-trivial destructor
+}
+static_assert(__is_trivially_relocatable(VD3), "");
+
+
+struct VB : public virtual T1 {
+    VB(const VB&) = default;
+    VB(VB&&) = default;
+    ~VB() = default;
+};
+void relocate_example(VB&& src) {
+    VB dst(static_cast<VB&&>(src));  // this MAY copy the virtual bases of "src" in a way not tantamount to memcpy
+    src.~VB();  // this calls the trivial destructor
+}
+static_assert(__is_trivially_destructible(VB), "");
+static_assert(!__is_trivially_constructible(VB, VB&&), "");
+static_assert(!__is_trivially_relocatable(VB), "");
+
+struct VB2 final : public virtual T1 {
+    VB2(const VB2&) = default;
+    VB2(VB2&&) = default;
+    ~VB2() = default;
+};
+void relocate_example(VB2&& src) {
+    VB2 dst(static_cast<VB2&&>(src));  // this MAY STILL copy the VBPTR of "src" in a way not tantamount to memcpy
+    src.~VB2();  // this calls the trivial destructor
+}
+static_assert(__is_trivially_destructible(VB2), "");
+static_assert(!__is_trivially_constructible(VB2, VB2&&), "");
+static_assert(!__is_trivially_relocatable(VB2), "");
+
+
+struct CCNMC {
+    CCNMC(const CCNMC&) = default;
+    // no move constructor at all
+    ~CCNMC() = default;
+};
+void relocate_example(CCNMC&& src) {
+    CCNMC dst(static_cast<CCNMC&&>(src));  // this calls the trivial copy-constructor
+    src.~CCNMC();  // this calls the trivial destructor
+}
+static_assert(__is_constructible(CCNMC, CCNMC&&), "");
+static_assert(__is_trivially_relocatable(CCNMC), "");
+
+
+struct CCDMC {
+    CCDMC(const CCDMC&) = default;
+    CCDMC(CCDMC&&) = delete;
+    ~CCDMC() = default;
+};
+void relocate_example(CCDMC&& src) {
+    // CCDMC dst(static_cast<CCDMC&&>(src));  // this is not permitted
+    src.~CCDMC();  // this calls the trivial destructor
+}
+static_assert(!__is_constructible(CCDMC, CCDMC&&), "");
+static_assert(!__is_trivially_relocatable(CCDMC), "");
+
+struct DD { ~DD() = delete; };
+static_assert(__is_trivially_copyable(DD), "");
+static_assert(!__is_trivially_destructible(DD), "");
+static_assert(!__is_trivially_relocatable(DD), "");
+
+
+struct T5 { int x; T5(T5&&) {} };
+static_assert(!__is_trivially_relocatable(T5), "");
+
+struct T6 { int x; ~T6() {} };
+static_assert(!__is_trivially_relocatable(T6), "");
+
+struct T7 { int x; T7(const T7&) {} };
+static_assert(!__is_trivially_relocatable(T7), "T7 has no implicitly declared move constructor");
+
+struct T8 { virtual void f() {} int x; };
+static_assert(__is_trivially_relocatable(T8), "T8 has a vptr but that's fine");
+
+struct [[trivially_relocatable]] T9 { int x; T9(T9&&) {} };
+static_assert(__is_trivially_relocatable(T9), "T9 isn't naturally, but it has the attribute");
+
+struct [[trivially_relocatable]] T10 { int x; ~T10() {} };
+static_assert(__is_trivially_relocatable(T10), "T10 isn't naturally, but it has the attribute");
+
+struct T11 {
+    T11();
+    T1 a;
+    T2 b;
+    T3 c;
+    T4 d;
+    T8 e;
+    T9 f;
+    T10 g;
+};
+static_assert(__is_trivially_relocatable(T11), "all fields have trivially relocatable types");
+
+struct T12 {
+    T1 a;
+    T2 b;
+    T3 c;
+    T5 d;  // not trivially relocatable
+    T8 e;
+    T9 f;
+    T10 g;
+};
+static_assert(!__is_trivially_relocatable(T12), "not all fields have trivially relocatable types");
+
+struct T13 : T1, T2, T3, T4 {};
+static_assert(__is_trivially_relocatable(T13), "all bases have trivially relocatable types");
+
+struct T14 : T1, T6, T3, T4 {};
+static_assert(!__is_trivially_relocatable(T14), "all bases have trivially relocatable types");
+
+template<class... Ts>
+struct T15 : Ts... {};
+
+static_assert(__is_trivially_relocatable(T15<T1,T2,T3>), "all bases have trivially relocatable types");
+static_assert(!__is_trivially_relocatable(T15<T1,T6,T3>), "not all bases have trivially relocatable types");
+
+template<class... Ts>
+struct [[trivially_relocatable]] T16 : Ts... {};
+
+static_assert(__is_trivially_relocatable(T16<T1,T2,T3>), "all bases have trivially relocatable types");
+static_assert(__is_trivially_relocatable(T16<T1,T6,T3>), "not naturally, but it has the attribute");
+
+struct T17 : T15<T10> {};  // T10 is trivially relocatable
+static_assert(__is_trivially_relocatable(T17), "");
+static_assert(__is_trivially_relocatable(T15<T17>), "");
+static_assert(__is_trivially_relocatable(T16<T17>), "");
+
+struct T18 : T15<T12> {};  // T12 is not trivially relocatable
+static_assert(!__is_trivially_relocatable(T18), "");
+static_assert(!__is_trivially_relocatable(T15<T18>), "");
+static_assert(__is_trivially_relocatable(T16<T18>), "not naturally, but it has the attribute");
+
+
+struct T19 {
+    struct [[trivially_relocatable]] UniquePtr {
+        UniquePtr();
+        UniquePtr(const UniquePtr&) = delete;
+        UniquePtr(UniquePtr&&);
+        ~UniquePtr();
+    };
+    UniquePtr m;
+    T19(const T19&) {}
+    T19(T19&&) = default;
+};
+
+static_assert(!__is_trivially_constructible(T19, const T19&), "user-provided copy constructor");
+static_assert(!__is_trivially_constructible(T19, T19&&), "defaulted non-trivial move constructor");
+static_assert(!__is_trivially_destructible(T19), "defaulted non-trivial destructor");
+static_assert(__is_trivially_relocatable(T19), "nevertheless, the Rule of Zero applies here");
+
+
+struct T20 {
+    struct [[trivially_relocatable]] SharedPtr {
+        SharedPtr();
+        SharedPtr(const SharedPtr&);
+        SharedPtr(SharedPtr&&);
+        ~SharedPtr();
+    };
+    SharedPtr m;
+    T20(const T20&) = default;
+    ~T20() = default;
+    // no move constructor
+};
+void relocate_example(T20&& src) {
+    T20 dst(static_cast<T20&&>(src));  // this calls the defaulted copy constructor and makes a COPY of the SharedPtr
+    src.~T20();  // this calls the destructor and deletes the original copy
+}
+static_assert(__is_trivially_relocatable(T20::SharedPtr), "because it's annotated");
+static_assert(!__is_trivially_constructible(T20, const T20&), "defaulted, non-trivial copy constructor");
+static_assert(__is_constructible(T20, T20&&), "uses the copy constructor");
+static_assert(!__is_trivially_constructible(T20, T20&&), "uses the copy constructor");
+static_assert(!__is_trivially_destructible(T20), "defaulted non-trivial destructor");
+static_assert(__is_trivially_relocatable(T20), "I'm not sure but I think copy-and-destroy should always be assumed tantamount to move-and-destroy");
+
+
+struct T21 {
+    struct [[trivially_relocatable]] SharedPtr {
+        SharedPtr();
+        SharedPtr(const SharedPtr&);
+        SharedPtr(SharedPtr&&);
+        ~SharedPtr();
+    };
+    SharedPtr m;
+    T21(const T21&);  // user-provided
+    ~T21() = default;
+    // no move constructor
+};
+void relocate_example(T21&& src) {
+    T21 dst(static_cast<T21&&>(src));  // this calls the user-provided copy constructor
+    src.~T21();  // this calls the defaulted destructor
+}
+static_assert(__is_trivially_relocatable(T21::SharedPtr), "because it's annotated");
+static_assert(!__is_trivially_constructible(T21, const T21&), "non-defaulted, non-trivial copy constructor");
+static_assert(__is_constructible(T21, T21&&), "uses the copy constructor");
+static_assert(!__is_trivially_constructible(T21, T21&&), "uses the copy constructor");
+static_assert(!__is_trivially_destructible(T21), "defaulted non-trivial destructor");
+static_assert(!__is_trivially_relocatable(T21), "Relocating T21 calls T21's user-provided copy constructor, which we don't know what it does");
+
+
+struct T22 {
+    struct [[trivially_relocatable]] MoveOnly { MoveOnly(MoveOnly&&); };
+    struct CopyOnly { ~CopyOnly() = default; };
+    MoveOnly m1;
+    CopyOnly m2;
+};
+void relocate_example(T22&& src) {
+    T22 dst(static_cast<T22&&>(src));  // this moves m1 (user-provided) and copies m2 (trivial, defaulted)
+    src.~T22();  // this destroys m1 (trivial, defaulted) and m2 (trivial, defaulted)
+}
+static_assert(!__is_constructible(T22::MoveOnly, const T22::MoveOnly&), "");
+static_assert(__is_constructible(T22::MoveOnly, T22::MoveOnly&&), "");
+static_assert(!__is_trivially_constructible(T22::MoveOnly, T22::MoveOnly&&), "");
+static_assert(__is_trivially_relocatable(T22::MoveOnly), "because it's annotated");
+static_assert(__is_constructible(T22::CopyOnly, const T22::CopyOnly&), "");
+static_assert(__is_constructible(T22::CopyOnly, T22::CopyOnly&&), "");
+static_assert(__is_trivially_constructible(T22::CopyOnly, const T22::CopyOnly&), "");
+static_assert(__is_trivially_constructible(T22::CopyOnly, T22::CopyOnly&&), "");
+static_assert(__is_trivially_relocatable(T22::CopyOnly), "because its copy constructor is defaulted and its move constructor doesn't exist");
+static_assert(!__is_constructible(T22, const T22&), "m1 is not copyable");
+static_assert(__is_constructible(T22, T22&&), "");
+static_assert(!__is_trivially_constructible(T22, T22&&), "m2 is not trivially moveable");
+static_assert(__is_trivially_destructible(T22), "both members are trivially destructible");
+static_assert(__is_trivially_relocatable(T22), "because its members are trivially relocatable");
+
+
+struct T23 {
+    struct Evil { Evil(Evil&); Evil(Evil&&) = default; ~Evil() = default; };
+    mutable Evil m;
+};
+void relocate_example(T23&& src) {
+    T23 dst(static_cast<T23&&>(src));  // this moves m (trivial, defaulted)
+    src.~T23();  // this destroys m (trivial, defaulted)
+}
+static_assert(__is_trivially_relocatable(T23::Evil), "because it is trivially move-constructible and destructible");
+static_assert(__is_constructible(T23, T23&&), "");
+static_assert(__is_constructible(T23, T23&), "");
+static_assert(!__is_constructible(T23, const T23&), "");
+static_assert(!__is_trivially_relocatable(T23), "because its copy operation is evil");
+
+struct T23a {
+    struct Evil { Evil(Evil&); Evil(const Evil&) = default; ~Evil() = default; };
+    mutable Evil m;
+};
+void relocate_example(T23a&& src) {
+    T23a dst(static_cast<T23a&&>(src));  // this copies m using the non-defaulted copy constructor
+    src.~T23a();  // this destroys m (trivial, defaulted)
+}
+static_assert(__is_trivially_relocatable(T23a::Evil), "its defaulted move-constructor is trivial");
+static_assert(__is_constructible(T23a, T23a&&), "");
+static_assert(__is_constructible(T23a, T23a&), "");
+static_assert(__is_constructible(T23a, const T23a&), "");
+static_assert(!__is_trivially_relocatable(T23a), "because its copy operation is evil");
+
+
+// Example from D1144R0
+struct string {
+    char *data_;
+    unsigned long size_ = 0;
+    unsigned long capacity_ = 0;
+    string() = default;
+    string(const char *s);
+    string(string&& s);
+    ~string();
+};
+static_assert(!__is_trivially_relocatable(string), "");
+
+// Example from D1144R0
+struct offset_ptr {
+    unsigned long value_;
+    offset_ptr();
+    offset_ptr(void *p);
+    offset_ptr(const offset_ptr& rhs);
+    offset_ptr& operator=(const offset_ptr& rhs);
+    ~offset_ptr() = default;
+};
+static_assert(!__is_trivially_relocatable(offset_ptr), "");
+
+// Example from D1144R0
+struct registered_object {
+    registered_object();
+    registered_object(registered_object&&) = default;
+    registered_object(const registered_object&) = default;
+    registered_object& operator=(registered_object&&) = default;
+    registered_object& operator=(const registered_object&) = default;
+    ~registered_object();
+};
+struct Widget : registered_object {};
+static_assert(!__is_trivially_relocatable(registered_object), "");
+static_assert(!__is_trivially_relocatable(Widget), "");
+
+// Example from Nicolas Lesser
+struct NL1 {
+    NL1& operator=(NL1&&);
+};
+static_assert(!__is_trivially_relocatable(NL1), "");
+
+struct [[trivially_relocatable]] NL2 {
+// expected-error@-1{{cannot be applied to struct 'NL2' because it is not move-constructible}}
+    NL2& operator=(NL2&&);
+};
+static_assert(!__is_trivially_relocatable(NL2), "");
+
+union [[trivially_relocatable]] NL3 {
+// expected-error@-1{{cannot be applied to union 'NL3' because it is not destructible}}
+    struct [[trivially_relocatable]] String { String(String&&); ~String(); };
+    int i;
+    String s;
+};
+static_assert(!__is_trivially_relocatable(NL3), "");
+
+union [[trivially_relocatable]] NL4 {
+    struct [[trivially_relocatable]] String { String(String&&); ~String(); };
+    int i;
+    String s;
+    NL4(const NL4&);
+    ~NL4();
+};
+static_assert(__is_trivially_relocatable(NL4), "");