4 Commits

Author SHA1 Message Date
Jan Kokemüller
4f4690530e
[libc++] Ensure that std::expected has no tail padding (#69673)
Currently std::expected can have some padding bytes in its tail due to
[[no_unique_address]]. Those padding bytes can be used by other objects.
For example, in the current implementation:

  sizeof(std::expected<std::optional<int>, bool>) == 
    sizeof(std::expected<std::expected<std::optional<int>, bool>, bool>)

As a result, the data layout of an
  std::expected<std::expected<std::optional<int>, bool>, bool> 
can look like this:

              +-- optional "has value" flag
              |        +--padding
  /---int---\ |        |
  00 00 00 00 01 00 00 00
                |  |
                |  +- "outer" expected "has value" flag
                |
                +- expected "has value" flag

This is problematic because `emplace()`ing the "inner" expected can not
only overwrite the "inner" expected "has value" flag (issue #68552) but
also the tail padding where other objects might live.

This patch fixes the problem by ensuring that std::expected has no tail
padding, which is achieved by conditional usage of [[no_unique_address]]
based on the tail padding that this would create.

This is an ABI breaking change because the following property changes:

  sizeof(std::expected<std::optional<int>, bool>) <
    sizeof(std::expected<std::expected<std::optional<int>, bool>, bool>)

Before the change, this relation didn't hold. After the change, the relation
does hold, which means that the size of std::expected in these cases increases
after this patch. The data layout will change in the following cases where
tail padding can be reused by other objects:

  class foo : std::expected<std::optional<int>, bool> {
    bool b;
  };

or using [[no_unique_address]]:

  struct foo {
    [[no_unique_address]] std::expected<std::optional<int>, bool> e;
    bool b;
  };

The vendor communication is handled in #70820.
Fixes: #70494

Co-authored-by: philnik777 <nikolasklauser@berlin.de>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2024-01-22 09:05:39 -05:00
Louis Dionne
5f2da9c80d
[runtimes] Bump the supported AppleClang version to AppleClang 15 (#67065)
AppleClang 15 was released on September 18th and is now stable. Per our
policy, we're bumping the supported AppleClang compiler to the latest
release. This allows cleaning up the test suite, but most importantly
unblocking various other patches that are blocked on bumping the
compiler requirements.
2023-09-25 09:46:01 -04:00
Mark de Wever
b251879376 [libc++] Removes Clang 14 support.
Per our policy we only support the last two releases.

Reviewed By: #libc, EricWF, philnik

Differential Revision: https://reviews.llvm.org/D148359
2023-04-15 13:10:07 +02:00
Hui Xie
e356f681f6 [libc++] Implement std::expected P0323R12
Implement `std::expected` https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0323r12.html

Added tests

Differential Revision: https://reviews.llvm.org/D124516

address comment
2022-12-14 15:43:42 +00:00