[Bug] potential upcoming ABI break in libc++

[DanAlbert]

Description

tl;dr: do not use std::expected at ABI boundaries

https://discourse.llvm.org/t/abi-break-in-libc-for-a-17-x-guidance-requested/74483 warns about an impending ABI break required to fix UB in std::expected.

The good news is that atm the libc++ folks think the ABI break will only be rarely noticeable:

the ABI break actually only breaks some very specific cases. You have to have a type with more than one byte of tail padding and have the expected marked with [[no_unique_address]]

https://discord.com/channels/636084430946959380/636732894974312448/1168654171940065330

The discourse thread suggest we cherry-pick llvm/llvm-project#68733 to fix the UB, but they want to make a more complete (better performance?) fix going forward that will be an ABI break.

I don't think that's set in stone yet, but if you want to defend against incompatibility with future NDKs, don't use std::expected at ABI boundaries (that's mostly a problem for middleware vendors, if you build all your C++ code as part of your app, you should be safe) with r26 or older. We're considering potentially disabling std::expected in an r26 point release to avoid the bad ABI getting too far out into the wild.

Upstream bug

llvm/llvm-project#70708

Commit to cherry-pick

llvm/llvm-project#68733

Affected versions

r26

Canary version

No response

Host OS

Linux, Mac, Windows

Host OS version

any

Affected ABIs

armeabi-v7a, arm64-v8a, x86, x86_64

[DanAlbert]

Not a regression, so whether or not this is included in r26c will depend on whether it's a clean cherry-pick or not.

[pirama-arumuga-nainar]

Doesn't cherry-pick cleanly to r26's toolchain. Safer to punt to r27 (where this will apply cleanly: branch point: Oct 25, fix merge date: Oct 30).

[DanAlbert]

SGTM, thanks for checking.