This is a breaking change. If you were passing one of those three runtimes
in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES
instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using
the "bootstrapping build" instead, which means that they will be built
using the just-built Clang. This is usually what you wanted anyway.
If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of
building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all
and these runtimes will be built using the bootstrapping build.
Differential Revision: https://reviews.llvm.org/D132480
In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.
After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).
However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.
This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.
Fixes#57440
Differential Revision: https://reviews.llvm.org/D133377
It seems these includes are still provided by the sub headers, so it only
removes the duplicates.
There is no change in the list of includes, but the change affects the
modular build. By not having the includes in the top-level header the
module map has changed. This uncovers missing includes in the tests
and missing exports in the module map. This causes the huge amount of
changes in the patch.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133252
This change implements the C library dependent portions of P0482R6
(char8_t: A type for UTF-8 characters and strings (Revision 6)) by
declaring std::c8rtomb() and std::mbrtoc8() in the <cuchar> header
when implementations are provided by the C library as specified by
WG14 N2653 (char8_t: A type for UTF-8 characters and strings
(Revision 1)) as adopted for C23.
A _LIBCPP_HAS_NO_C8RTOMB_MBRTOC8 macro is defined by the libc++ __config
header unless it is known that the C library provides these functions
in the current compilation mode. This macro is used for testing purposes
and may be of use to libc++ users. At present, the only C library known
to implement these functions is GNU libc as of its 2.36 release.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D130946
During the discussion on the SG-10 mailinglist regarding the format
feature-test macros voted in during the last plenary it turns out libc++
can't mark the format feature-test macro as implemented.
According to
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_lib_format
the not yet implemented paper
P1361R2 Integration of chrono with text formatting
affects the feature test macro.
Note that P1361R2 doesn't mention the feature-test macro nor is there an
LWG-issue to address the issue. The reporter of the issue didn't recall
where this requirement exactly has been decided.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D133271
Adding `[[nodiscard]]` to functions is a conforming extension and done extensively in the MSVC STL.
Reviewed By: ldionne, EricWF, #libc
Spies: #libc_vendors, cjdb, mgrang, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128267
This defines a new policy for removal of transitive includes.
The goal of the policy it to make it relatively easy to remove
headers when needed, but avoid breaking developers using and
vendors shipping libc++.
The method used is to guard transitive includes based on the
C++ language version. For the upcoming C++23 we can remove
headers when we want, but for other language versions we try
to keep it to a minimum.
In this code the transitive include of `<chrono>` is removed
since D128577 introduces a header cycle between `<format>`
and `<chrono>`. This cycle is indirectly required by the
Standard. Our cycle dependency tool basically is a grep based
tool, so it needs some hints to ignore cycles. With the input
of our transitive include tests we can create a better tool.
However that's out of the scope of this patch.
Note the flag `_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` remains
unchanged. So users can still opt-out of transitives includes
entirely.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D132284
Implements:
- LWG3721 Allow an arg-id with a value of zero for width in std-format-spec
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130649
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Previously the specification was in a table in paragraph 14 of [container.requirements.general] but it has since been given its own sub section header, 24.2.2.4 [container.opt.reqmts].
This happened in 93ff092d1c
This update also includes misc. other cleanups of the spaceship projects sheet.
Reviewed By: Mordante, avogelsgesang, #libc
Differential Revision: https://reviews.llvm.org/D131928
The new operator<=> is mapped onto the existing functions
__libcpp_thread_id_equal and __libcpp_thread_id_less. Introducing a
new __libcpp_thread_id_compare_three_way might lead to more efficient
code. Given that we can still introduce __libcpp_thread_id_compare_three_way
later, for this commit I opted to not break ABI. If requested, I will
add __libcpp_thread_id_compare_three_way in a follow-up commit.
Implements part of P1614R2 "The Mothership has Landed"
Differential Revision: https://reviews.llvm.org/D131362
D131234 marked the ranges papers as complete, but it didn't set the
feature-test macro.
Reviewed By: ldionne, var-const, #libc
Differential Revision: https://reviews.llvm.org/D131326
When back-deploying to older platforms, we can still provide assertions,
but we might not be able to provide a great implementation for the verbose
handler. Instead, we can just call ::abort().
Differential Revision: https://reviews.llvm.org/D131199
The newly-completed papers:
- P0896R4 ("The One Ranges Proposal");
- P1243R4 ("Rangify New Algorithms");
- P1252R2 ("Ranges Design Cleanup");
- P1716R3 ("Range Comparison Algorithms Are Over-Constrained");
- P1871R1 ("Concept traits should be named after concepts");
- P2106R0 ("Alternative wording for GB315 and GB316").
Differential Revision: https://reviews.llvm.org/D131234
Also fix `ranges::stable_sort` and `ranges::inplace_merge` to support
proxy iterators now that their internal implementations can correctly
dispatch `rotate`.
Differential Revision: https://reviews.llvm.org/D130758
Louis Dionne