You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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]]
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.
Description
tl;dr: do not use
std::expected
at ABI boundarieshttps://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:
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 disablingstd::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
The text was updated successfully, but these errors were encountered: