[clang] [clang] Implement a bitwise_copyable builtin type trait. (PR #86512)

[Sam McCall via cfe-commits]

https://github.com/sam-mccall commented:

I'm in favour of this, but we should have someone less-attached to it sign off on at least the basic design.

One question this doesn't explicitly address: after memcpying, does user code need to bless the bits somehow to start the new object's lifetime?

I think the answer should probably be yes, even if blessing is a no-op for now. https://github.com/llvm/llvm-project/pull/82776 seems suitable.

`__is_trivially_copyable` doesn't require this, but the types it applies to are pretty limited in terms of lifetime concerns, so I think it's OK to draw a distinction.

One argument for this is with no "bless" barrier, I don't understand exactly where the line is drawn for strict-aliasing purposes:
 - if we can memcpy an object A into a buffer B
 - then surely we can copy it ourselves byte-by-byte
 - and we can then immediately copy it back from B to A, if the destructor is trivial
 - now we get to treat it as a different type
 Here A's bytes didn't change - is the write to B important? Do we have to write the bytes sequentially for this transmutation of A to work, or can we reuse a single byte variable?

This all seems weird and like we're reinventing implicit-lifetime types. That's by necessity a weird feature, but the weirdness is not needed here.

https://github.com/llvm/llvm-project/pull/86512