This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Disable incomplete features for the LLVM 14 release
ClosedPublic

Authored by ldionne on Feb 3 2022, 6:44 AM.

Details

Reviewers
Mordante
Group Reviewers
Restricted Project
Restricted Project
Summary

For the LLVM 14 release, don't ship incomplete features (currently
ranges and format) by default. If some vendors want to ship those
features, they can override the CMake option manually. This is
consistent with what we did for LLVM 13.

Note that this patch is only aimed towards the release/14.x branch.

Diff Detail

Event Timeline

ldionne created this revision.Feb 3 2022, 6:44 AM
ldionne requested review of this revision.Feb 3 2022, 6:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2022, 6:44 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Mordante added inline comments.
libcxx/CMakeLists.txt
136

No objection to this change. However I think the release notes need to be updated. The first bullet regarding <format> contains the wording.

Vendors can still disable this header by turning the CMake option
LIBCXX_ENABLE_INCOMPLETE_FEATURES off.

The current wording implies ON is the default.

ldionne updated this revision to Diff 405808.Feb 3 2022, 3:05 PM
ldionne marked an inline comment as done.

Address review comments, rebase and fix CI by excluding the format symbols from the ABI list by default
(since by default, we're effectively not including those symbols in the dylib).

Mordante added inline comments.Feb 3 2022, 11:12 PM
libcxx/docs/ReleaseNotes.rst
47
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist
1044

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?

ldionne updated this revision to Diff 405964.Feb 4 2022, 7:31 AM
ldionne marked 2 inline comments as done.

Address review comments and try to fix GCC build

ldionne added inline comments.Feb 4 2022, 7:31 AM
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist
1044

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.

Mordante accepted this revision as: Mordante.Feb 4 2022, 9:12 AM

LGTM after the CI passes.

libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist
1044

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.

Quuxplusone added inline comments.
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist
1044

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.

ldionne added inline comments.Feb 4 2022, 9:44 AM
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist
1044

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.

ldionne updated this revision to Diff 406025.Feb 4 2022, 10:05 AM

Try to fix the GCC build again, less invasively.

Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2022, 10:05 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Mordante added inline comments.Feb 4 2022, 10:50 AM
libcxx/lib/abi/arm64-apple-darwin.libcxxabi.v1.stable.exceptions.no_new_in_libcxx.abilist
1044

@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.)

ldionne updated this revision to Diff 406060.Feb 4 2022, 11:37 AM

Try to fix the CI -- I think this should be good.

This is kind of nasty, I'll have to cherry-pick some of these changes back onto main.
There's a couple of problems:

  1. The benchmarks didn't work when incomplete features were disabled -- that's trivial to fix
  2. The modular build is not compatible with various knobs we have in the __config_site. For example, you can't use the modular build with LIBCXX_ENABLE_LOCALIZATION=OFF. A lot of stuff is going to break. In this patch, I am fixing just enough for the modular build to work when incomplete features are disabled, but we should really investigate the situation so that the modular build works with all configuration knobs.
ldionne accepted this revision as: Restricted Project, Restricted Project.Feb 4 2022, 12:25 PM

CI is passing. I'm going to push this because I really want to land this in the 14 release. I'll then cherry-pick bits and pieces back onto main and we can solve some of the underlying issues separately.

This revision is now accepted and ready to land.Feb 4 2022, 12:25 PM