[PATCH] D50119: Compiler support for P1144R0 "__is_trivially_relocatable(T)"

Arthur O'Dwyer via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Nov 17 12:01:33 PST 2018


Quuxplusone updated this revision to Diff 174513.
Quuxplusone added a comment.

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


Repository:
  rC Clang

https://reviews.llvm.org/D50119

Files:
  docs/LanguageExtensions.rst
  include/clang/AST/DeclCXX.h
  include/clang/AST/Type.h
  include/clang/Basic/Attr.td
  include/clang/Basic/AttrDocs.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Features.def
  include/clang/Basic/TokenKinds.def
  include/clang/Basic/TypeTraits.h
  lib/AST/ASTImporter.cpp
  lib/AST/DeclCXX.cpp
  lib/AST/Type.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriter.cpp
  test/Lexer/has_extension_cxx.cpp
  test/Misc/pragma-attribute-supported-attributes-list.test
  test/SemaCXX/maybe-trivially-relocatable.cpp
  test/SemaCXX/trivially-relocatable.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D50119.174513.patch
Type: text/x-patch
Size: 75683 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20181117/5a6352bb/attachment-0001.bin>


More information about the cfe-commits mailing list