[PATCH] D114902: [Attrs] Elaborate on the trivial_abi documentation

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

LgenerallyGTM!

- I would say "special member functions" instead of "methods"
- instead of "passed indirectly by address", consider saying "passed by hidden reference" — is this something people will get, or is it a me-ism? :) There are lots of Google hits for "by hidden reference," including apparently some ABI docs.
- "mark [...] as safe to //copy// as part of a function call" — Here you want a phrase that indicates "copy the bits, but don't 'copy' in the C++ sense of calling the copy constructor." One technically correct option would be to say "trivially relocate" (you mean "relocate" not "copy", and it's going to be trivial because you're just copying the bits). Alternatively, maybe say something more verbose about how the object will be seen to "jump" from one address to another with no intervening ctor or dtor calls — and this "jump" will happen precisely at the point of the call. The object goes from //memory// (in the caller's frame), into a //register//, and then back into //memory// again (at a new address in the callee's frame). This attribute is safe to use only when such "jumps" are unobservable by (or harmless to) the program.  [I know //you// know this; I just don't think your wording makes it crystal clear to the future //reader// that this is what you mean.]
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1144r5.html#non-trivial-samples contains all the examples of non-trivially-relocatable types I can think of. A big one is libc++ `std::list` and `std::map`. You allude to these with the words "Objects that register themselves into a doubly linked list", but I think that requires eagle eyes on the reader's part. "Objects whose address escapes onto the heap ... `std::list`" probably deserves its own dedicated bullet point, called out separately from "side table of live instances [...] debug iterators."
- Also, objects with vptrs should never be considered trivially relocatable; but that's so arcane that I'm happy not to mention it here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114902