[libcxx-commits] [PATCH] D118901: [libc++] Disable incomplete features for the LLVM 14 release

Arthur O'Dwyer via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Feb 4 09:20:28 PST 2022


Quuxplusone added inline comments.


================
Comment at: libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist:1044
-{'is_defined': True, 'name': '__ZNSt3__112format_errorD1Ev', 'type': 'FUNC'}
-{'is_defined': True, 'name': '__ZNSt3__112format_errorD2Ev', 'type': 'FUNC'}
 {'is_defined': True, 'name': '__ZNSt3__112future_errorC1ENS_10error_codeE', 'type': 'FUNC'}
----------------
Mordante wrote:
> ldionne wrote:
> > Mordante wrote:
> > > I expect this to break the ABI check target in CMake when `LIBCXX_ENABLE_INCOMPLETE_FEATURES` is turned on, am I ?
> > > Should we use different ABI lists depending on the state of the `LIBCXX_ENABLE_INCOMPLETE_FEATURES` flag?
> > Yes, that will break the ABI check target when `LIBCXX_ENABLE_INCOMPLETE_FEATURES=ON`, however on the `release/14.x` branch, that is never the case, so it's no big deal. This is arguably a bit hacky.
> > 
> > In the future, what I want instead is to ship those symbols inside `c++experimental.a`, and vendors can actually ship that static archive. We'd also add a Clang flag (something like `-fexperimental`) that controls whether those features are enabled so that users can play around with them. Since the symbols would be in `c++experimental.a`, we wouldn't put them in the ABI lists until they are moved into the main dylib anyway, and that would be a non issue.
> That sounds like a good future direction. That also makes it easier for users to decide whether or not to depend on these not complete features. Instead of vendors needing to make the choices.
That seems like a fine future direction, but notice that it doesn't help at all for Ranges (or the templated parts of Format); I think we're converging on the idea that the "ABI-dangerous" part of Ranges is stuff like `transform_view`, which are header-only.
Vice versa, I don't actually see what would be the problem with unconditionally shipping `__ZNSt3__112format_errorD0Ev` in our dylib. //That's// not the ABI-dangerous part of Format. Nothing about the ABI of `format_error` seems unstable to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118901/new/

https://reviews.llvm.org/D118901



More information about the libcxx-commits mailing list