[libcxx-commits] [libcxx] [libc++] Fix UB in <expected> related to "has value" flag (#68552) (PR #68733)

[Richard Smith via libcxx-commits]

Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>,
Jan =?utf-8?q?Kokemüller?= <jan.kokemueller at gmail.com>
Message-ID:
In-Reply-To: <llvm/llvm-project/pull/68733/libcxx at github.com>


zygoloid wrote:

> Would you folks agree with the following general guideline?
> 
> > Never use `std::construct_at` on something that is marked as `[[no_unique_address]]` because it potentially leads to overwriting tail padding that you might not own (in case the compiler jammed another object into it).
> 
> @zygoloid Is that basically the mental model we should have? If so, would it make sense to have a compiler warning for that?

Yes. See my comment here: https://github.com/llvm/llvm-project/pull/69673#pullrequestreview-1690703557 -- the more general rule is that you cannot transparently replace a potentially overlapping object, where:

- Transparently replace: construct a new object in the location where an existing object was without destroying the enclosing object, and with references, pointers and names that referred to the existing object transparently changing to refer to the new one.
- Potentially overlapping: either a base class subobject or a `[[no_unique_address]]` member subobject.

I think we should be able to produce a compiler warning in cases where it's locally obvious this is happening. We should also fix clang's constant evaluator to not let you get away with breaking this rule.

Separately, I think it'd be a good idea to explore a language extension to allow constructing over the top of a `[[no_unique_address]]` subobject without clobbering fields in its tail padding. We'd probably want a variant of a `new` expression that's somehow annotated to say "this isn't a complete object, don't assume you can write over the whole thing". We *should* be able to get the `std::expected` layout that libc++ originally wanted here, and it's disappointing that there's no way to express that in standard C++.

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