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

[Louis Dionne via Phabricator via libcxx-commits]

ldionne 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'}
----------------
Quuxplusone wrote:
> 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.
You're right, it's just that we might as well wait to ship all of format before shipping any of it.

I do think that `-fexperimental` will help for Ranges, because `-fexperimental` will be documented as being unstable and not to be used for production code. That way, we can ship half-baked stuff and keep changing them until we're confident that they'll be stable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118901