[libc++] Vendor communication: upcoming ABI breaks in std::expected and parts of <ranges>

[ldionne]

Hi @llvm/libcxx-vendors,

This issue is not a traditional issue. It is a communication to vendors about upcoming ABI breaks in std::expected and some parts of <ranges>. It was recently brought to our attention in #70494 (see the associated PR for more discussion) that there is a problem with some of the library's usage of [[no_unique_address]], which can lead to objects overlapping with padding bytes of other objects and their contents being overwritten unexpectedly.

We are aware of this issue in std::expected and in std::__movable_box, which is used to implement several views in <ranges>. Fixing this will require breaking the ABI for the types involved. We introduced std::expected and __movable_box in LLVM 16 so this has been shipping for two releases. We are aiming to fix these issues in LLVM 18.

Typically, we do not expect code to expose a lot of <ranges> views at ABI boundaries, so we believe the __movable_box ABI break to have a limited fallout. However, std::expected is a vocabulary type and is intended to appear at all kinds of API (and ABI) boundaries, in particular function result types. That ABI break is more likely to cause actual issues in the wild.

At this moment, we want to make vendors aware of these upcoming changes so they can plan ahead and perhaps limit the blast radius in case they haven't shipped LLVM 16/17 yet. One possibility would be to disable std::expected in their downstream release or keep it experimental behind -fexperimental-library. We will update this thread as we gain more clarity on the exact nature of the upcoming ABI break (e.g. which types are impacted and under what circumstances).

FAQ

Q: Are you going to allow vendors to opt into the old/new ABI for these types?
A: No. The current ABI has correctness issues which are serious enough that nobody should opt into the old ABI. This isn't a performance improvement or a slight conformance fix.

Q: Are you going to take this opportunity to enable other ABI breaks, effectively moving to "ABI v2"?
A: No. The intent of these changes is to keep the ABI break as narrow as possible with the hopes that the actual fallout will be limited. <ranges> is seldom used at ABI boundaries. std::expected shipped only recently, requires C++23 and we expect that few users will have had the time to depend on it in their ABI.

Q: Is it possible to use some techniques to try and diagnose when folks have an ABI mismatch after shipping that ABI break?
A: Yes, to some extent. We will use ABI tags to influence the mangling of functions that contain a type that undergoes an ABI break. This means that trying to link two units using/providing a function whose signature contains e.g. std::expected will fail at link time since the mangled name of the function will be different between LLVM 17 and LLVM 18. However, this technique has limitations. For example, if a std::expected is contained in a user-defined class, the user-defined class will not get an ABI tag despite its layout potentially changing between LLVM 17 and LLVM 18.

[ldionne]

Dropping a few links here for cross-reference purposes

• Discourse announcement to vendors about the upcoming ABI break: https://discourse.llvm.org/t/libc-vendor-announcement-upcoming-abi-break-in-std-expected-and-parts-of-ranges-in-llvm-18
• Discourse post asking for guidance for LLVM 17 (turns out we won't break anything in LLVM 17): https://discourse.llvm.org/t/abi-break-in-libc-for-a-17-x-guidance-requested
• Issue describing the problem about tail padding being reused: [libc++] std::expected: operations may overwrite bytes of unrelated objects #70494
• PR fixing the tail padding issue: [libc++] Ensure that std::expected has no tail padding #69673
• Issue describing the same tail padding problem for __movable_box: [libc++] std::ranges::__movable_box can overwrite data that comes after it #70506
• PR fixing the tail padding issue for __movable_box: [libc++][ranges][abi-break] Fix movable_box overwriting memory of data that lives in the tail padding #71314
• Related issue that led to the tail padding issue being discovered (not ABI breaking, fixed in LLVM 17): [libc++] std::expected "has value" flag getting clobbered unexpectedly #68552
• PR fixing this related issue: [libc++] Fix UB in <expected> related to "has value" flag (#68552) #68733

[ldionne]

All the changes related to this event have now been merged:

• [libc++][ranges][abi-break] Fix movable_box overwriting memory of data that lives in the tail padding #71314
• [libc++] Fix UB in <expected> related to "has value" flag (#68552) #68733
• [libc++] Ensure that std::expected has no tail padding #69673

Effect on <ranges>

The following components from <ranges> have an ABI break: take_while_view, filter_view, single_view, drop_while_view, repeat_view, transform_view, and chunk_by_view. We added an ABI tag to these classes such that trying to link programs using different versions of these views will produce a linker error.

Effect on std::expected

Some user-defined types containing a std::expected<T, E> member will have an ABI break. However, such ABI break requires a fairly uncommon set of conditions:

• A type equivalent to union {T ; E} needs to have more than one byte of padding available.
• The std::expected<T, E> member must have been in a situation where its padding bytes were previously reused by another object, which can happen in a few cases (this is probably not exhaustive):
  • It is a member with [[no_unique_address]] applied to it, and it is followed by another data member, or
  • It is a member with [[no_unique_address]] applied to it, and it is the last member of the user-defined type,
    and that user-defined type is used in ways that its padding bytes can be reused, or
  • It is inherited from

Overall, we expect (and hope) the breakage is not widespread due to the rarity of these conditions. Furthermore, under these conditions the code would have previously been broken due to the bug we're fixing.

We did not add an ABI tag to std::expected because the breakage only arises for types that contain a std::expected as a member, and adding an ABI tag in that case doesn't help. Adding an ABI tag would have simply caused a lot of spurious link-time breakage for cases where the ABI didn't actually change.

I will close this issue now, if vendors have questions please feel free to ask them here and perhaps ping me to make sure I see the notification.