devin.jeanpierre created this revision. devin.jeanpierre added reviewers: rsmith, rjmccall. devin.jeanpierre requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits.
Previous change: D114732 <https://reviews.llvm.org/D114732> The wording here might need some tweaking. What I want to guarantee is that everything valid for an implicit-lifetime type is also valid for these types. Either they're added to the set of implicit-lifetime types as an extension, or the operations are valid for additional non-implicit-lifetime types -- something like that. Something to this effect is required for it to be defined behavior to `memcpy` to a new location, and then use the type at that new location. And so, this guarantee is necessary for `__is_trivially_relocatable` to be actually useful in practice. See e.g. D119385 <https://reviews.llvm.org/D119385> for how this plays out. AIUI, Clang is already fine with this and needs no code changes. Indeed, we see many types which are not what the standard would call implicit-lifetime, yet which use memcpy for copying: `std::vector` only checks for trivial move, and does not pair this with requiring trivial destroy. (See e.g. `__construct_forward_with_exception_guarantees`) (Specifically: I believe that Clang is already fine with treating any non-polymorphic type as if it were implicit-lifetime, but I am not sure how to check this belief. There's not much in the way of explicit references to "implicit-lifetime" types in the codebase. Had a brief out of band conversation with rsmith, but may of course have misunderstood the conclusions here.) Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D120086 Files: clang/docs/LanguageExtensions.rst Index: clang/docs/LanguageExtensions.rst =================================================================== --- clang/docs/LanguageExtensions.rst +++ clang/docs/LanguageExtensions.rst @@ -1372,8 +1372,9 @@ * ``__is_trivially_relocatable`` (Clang): Returns true if moving an object of the given type, and then destroying the source object, is known to be functionally equivalent to copying the underlying bytes and then dropping the - source object on the floor. This is true of trivial types and types which - were made trivially relocatable via the ``clang::trivial_abi`` attribute. + source object on the floor. (Note: any such type is, therefore, implicit-lifetime.) + This is true of trivial types and types which were made trivially relocatable + via the ``clang::trivial_abi`` attribute. * ``__is_union`` (C++, GNU, Microsoft, Embarcadero) * ``__is_unsigned`` (C++, Embarcadero): Returns false for enumeration types. Note, before Clang 13, returned true for
Index: clang/docs/LanguageExtensions.rst =================================================================== --- clang/docs/LanguageExtensions.rst +++ clang/docs/LanguageExtensions.rst @@ -1372,8 +1372,9 @@ * ``__is_trivially_relocatable`` (Clang): Returns true if moving an object of the given type, and then destroying the source object, is known to be functionally equivalent to copying the underlying bytes and then dropping the - source object on the floor. This is true of trivial types and types which - were made trivially relocatable via the ``clang::trivial_abi`` attribute. + source object on the floor. (Note: any such type is, therefore, implicit-lifetime.) + This is true of trivial types and types which were made trivially relocatable + via the ``clang::trivial_abi`` attribute. * ``__is_union`` (C++, GNU, Microsoft, Embarcadero) * ``__is_unsigned`` (C++, Embarcadero): Returns false for enumeration types. Note, before Clang 13, returned true for
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
