[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'}
----------------
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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118901