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

Mark de Wever via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Feb 4 09:12:21 PST 2022


Mordante accepted this revision as: Mordante.
Mordante added a comment.

LGTM after the CI passes.



================
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:
> 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.


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