Commit Graph

5 Commits

Author SHA1 Message Date
Louis Dionne 8711fcae27 [libc++] Treat incomplete features just like other experimental features
In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done through the
_LIBCPP_ENABLE_EXPERIMENTAL macro.

Also, never provide symbols related to incomplete features inside the
dylib, instead provide them in c++experimental.a (this changes the
symbols list, but not for any configuration that should have shipped).

Differential Revision: https://reviews.llvm.org/D128928
2022-07-19 10:50:20 -04:00
Louis Dionne 7300a651f5 [libc++] Re-apply "Always build c++experimental.a""
This re-applies bb939931a1, which had been reverted by 09cebfb978
because it broke Chromium. The issues seen by Chromium should be
addressed by 1d0f79558c.

Differential Revision: https://reviews.llvm.org/D128927
2022-07-19 10:44:19 -04:00
Hans Wennborg 09cebfb978 Revert "[libc++] Always build c++experimental.a"
This caused build failures when building Clang and libc++ together on Mac:

  fatal error: 'experimental/memory_resource' file not found

See the code review for details. Reverting until the problem and how to
solve it is better understood.

(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)

> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927

This reverts commit bb939931a1.
2022-07-18 16:57:15 +02:00
Louis Dionne bb939931a1 [libc++] Always build c++experimental.a
This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on them. Subsequent patches will
also encompass incomplete features (such as <format> and <ranges>)
in that categorization. Basically, the idea is that we always
build and ship the c++experimental library, however users can't
use what's in it unless they pass the `-funstable` flag to Clang.

Note that this patch intentionally does not start guarding
existing <experimental/FOO> content behind the flag, because
that would merely break users that might be relying on such
content being in the headers unconditionally. Instead, we
should start guarding new TSes behind the flag, and get rid
of the existing TSes we have by shipping their Standard
counterpart.

Also, this patch must jump through a few hoops like defining
_LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
that do not implement -funstable yet.

Differential Revision: https://reviews.llvm.org/D128927
2022-07-08 16:58:22 -04:00
Louis Dionne 99ae458231 [libc++] Add CI without experimental features and don't exclude span from the tests
There is no reason for the parts of std::span that don't depend on ranges
to be disabled when ranges aren't provided. Also, to make sure the
"no-experimental-stuff" configuration is tested, add a CI job for it.

Differential Revision: https://reviews.llvm.org/D118740
2022-02-02 10:48:35 -05:00