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

[Mark de Wever via Phabricator via libcxx-commits]

Mordante 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'}
----------------
ldionne wrote:
> 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.
@Quuxplusone having experimental library would make it possible to move more parts of `std::format` to the dylib. Due to ABI concerns I've avoided doing that. This is something at my todo list and has also been requested by @ldionne.

(Your observation regarding `format_error` is correct, that's ABI stable.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118901