Installs the source files of the experimental libc++ modules. These
source files (.cppm) are used by the Clang to build the std and
std.compat modules.
The design of this patch is based on a discussing in SG-15 on
12.12.2023. (SG-15 is the ISO C++ Tooling study group):
- The modules are installed at a location, that is not known to build
systems and compilers.
- Next to the library there will be a module manifest json file.
This json file contains the information to build the module from the
libraries sources. This information includes the location where the
sources are installed. @ruoso supplied the specification of this json
file.
- If possible, the compiler has an option to give the location of the
module manifest file
(https://github.com/llvm/llvm-project/pull/76451).
Currently there is no build system support, but it expected to be added
in the future.
Fixes: https://github.com/llvm/llvm-project/issues/73089
Revert "Revert #76246 and #76083"
This reverts commit 5c150e7eeba9db13cc65b329b3c3537b613ae61d.
Adds a small fix that should properly disable the tests on Windows.
Unfortunately the original poster has not provided feedback and the
original patch did not fail in the LLVM CI infrastructure.
Modules are known to fail on Windows due to non compliance of the
C library. Currently not having this patch prevents testing on other
platforms.
In the hardening modes that can be used in production (`fast` and
`extensive`), make a failed assertion invoke a trap instruction rather
than calling verbose abort. In the debug mode, still keep calling
verbose abort to provide a better user experience and to allow us to
keep our existing testing infrastructure for verifying assertion
messages. Since the debug mode by definition enables all assertions, we
can be sure that we still check all the assertion messages in the
library when running the test suite in the debug mode.
The main motivation to use trapping in production is to achieve better
code generation and reduce the binary size penalty. This way, the
assertion handler can compile to a single instruction, whereas the
existing mechanism with verbose abort results in generating a function
call that in general cannot be optimized away (made worse by the fact
that it's a variadic function, imposing an additional penalty). See the
[RFC](https://discourse.llvm.org/t/rfc-hardening-in-libc/73925) for more
details. Note that this mechanism can now be completely [overridden at
CMake configuration
time](https://github.com/llvm/llvm-project/pull/77883).
This patch also significantly refactors `check_assertion.h` and expands
its test coverage. The main changes:
- when overriding `verbose_abort`, don't do matching inside the function
-- just print the error message to `stderr`. This removes the need to
set a global matcher and allows to do matching in the parent process
after the child finishes;
- remove unused logic for matching source locations and for using
wildcards;
- make matchers simple functors;
- introduce `DeathTestResult` that keeps data about the test run,
primarily to make it easier to test.
In addition to the refactoring, `check_assertion.h` can now recognize
when a process exits due to a trap.
These cause test build failures on Windows.
This reverts the following commits:
57ca74843586c9a93c425036c5538aae0a2cfa60
d06ae33ec32122bb526fb35025c1f0cf979f1090
Previously there were two ways to override the verbose abort function
which gets called when a hardening assertion is triggered:
- compile-time: define the `_LIBCPP_VERBOSE_ABORT` macro;
- link-time: provide a definition of `__libcpp_verbose_abort` function.
This patch adds a new configure-time approach: the vendor can provide
a path to a custom header file which will get copied into the build by
CMake and included by the library. The header must provide a definition
of the
`_LIBCPP_ASSERTION_HANDLER` macro which is what will get called should
a hardening assertion fail. As of this patch, overriding
`_LIBCPP_VERBOSE_ABORT` will still work, but the previous mechanisms
will be effectively removed in a follow-up patch, making the
configure-time mechanism the sole way of overriding the default handler.
Note that `_LIBCPP_ASSERTION_HANDLER` only gets invoked when a hardening
assertion fails. It does not affect other cases where
`_LIBCPP_VERBOSE_ABORT` is currently used (e.g. when an exception is
thrown in the `-fno-exceptions` mode).
The library provides a default version of the custom header file that
will get used if it's not overridden by the vendor. That allows us to
always test the override mechanism and reduces the difference in
configuration between the pristine version of the library and
a platform-specific version.
This removes the entire modules testing infrastructure.
The current infrastructure uses CMake to generate the std and std.compat
module. This requires quite a bit of plumbing and uses CMake. Since
CMake introduced module support in CMake 3.26, modules have a higher
CMake requirement than the rest of the LLVM project. (The LLVM project
requires 3.20.) The main motivation for this approach was how libc++
generated its modules. Every header had its own module partition. This
was changed to improve performance and now only two modules remain. The
code to build these can be manually crafted.
A followup patch will reenable testing modules, using a different
approach.
We discussed the removal of these enable-all macros in the libc++
monthly meeting and we agreed that we should deprecate these macros in
LLVM 18, and then remove them in LLVM 19 since they can silently enable
deprecated features that are implemented after the first release of the
macro.
This patch does the first part of this -- it deprecates the macro.
Note that the file
test/libcxx/depr/enable_removed_cpp20_features.compile.pass.cpp
does not exist so this file is not adapted. Since the feature is
deprecated and slated for removal soon the missing test is not
implemented.
Partly addresses: https://github.com/llvm/llvm-project/issues/75976
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
The old notes are kept to make it easier to backport changes to the
release branch. There are no LLVM-17 releases expected and this
documentation should not be available in the LLVM-18 release.
Note after branching LLVM-18 both LLVM-18 and LLVM-19 release notes
should be available.
As described in #69994, using the escape hatch makes us non-conforming
in C++20 due to incorrect constexpr-ness. It also leads to bad
diagnostics as reported by #63900. We discussed the issue in the libc++
monthly meeting and we agreed that we should deprecate the macro in LLVM
18, and then remove it in LLVM 19 since it causes too many problems.
This patch does the first part of this -- it deprecates the macro.
Fixes#69994Fixes#63900
Partially addresses #75975
I recently came across LIBCXXABI_USE_LLVM_UNWINDER and was surprised to
notice it was disabled by default. Since we build libunwind by default
and ship it in the LLVM toolchain, it would seem to make sense that
libc++ and libc++abi rely on libunwind for unwinding instead of using
the system-provided unwinding library (if any).
Most importantly, using the system unwinder implies that libc++abi is
ABI compatible with that system unwinder, which is not necessarily the
case. Hence, it makes a lot more sense to instead default to using the
known-to-be-compatible LLVM unwinder, and let vendors manually select a
different unwinder if desired.
As a follow-up change, we should probably apply the same default to
compiler-rt.
Differential Revision: https://reviews.llvm.org/D150897Fixes#77662
rdar://120801778
As pointed out by @Zingam the paper was implemented in libc++ as an
extension. This patch does the bookkeeping. The inital release version
is based on historical release dates.
Completes:
- Add a conditional noexcept specification to std::apply
fixes#70506
The detailed problem description is in #70506
The original proposed fix was to remove `[[no_unique_address]]` except
when `_Tp` is empty.
Edit:
After the discussion in the comments below, the new fix here is to
remove the `[[no_unique_address]]` from `movable_box` in the cases where
we need to add our own assignment operator, which has contains the
problematic `construct_at`
The status table incorrectly marks P0521R0 as nothing to do. This is not
correct the function should be deprecated.
During our latest monthly meeting we argreed to remove the
_LIBCPP_ENABLE_CXXyy_REMOVED_FEATURES macros, therefore the new macro is
not
added to that global list.
Implements
- P0521R0 Proposed Resolution for CA 14 (shared_ptr use_count/unique)
Implements parts of
- P0619R4 Reviewing Deprecated Facilities of C++17 for C++20
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
Finishes implementation of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be synchronized
with the underlying stream?
Differential Revision: https://reviews.llvm.org/D156609
This change requires quite a number of changes in the tests; this is not
code I expect people to use in the wild. So I don't expect breakage for
users.
Implements:
- P2905R2 Runtime format strings, as a Defect Report
This paper was voted in as a DR, so it's retroactively enabled back to
C++20; the C++ version that introduced std::format.
Implements:
- P2909R4 Fix formatting of code units as integers (Dude, where’s my
``char``?)
Several experimental headers around std::pmr have been slated for
removal for a while now. This patch actually performs the removal and
cleanups from the code base.
This patch re-introduces special support for narrowing conversions to
bool
in std::variant, which was removed in 170810fca6ee in order to make
libc++
Standards-conforming.
The special support is gated by the
`_LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT`
macro and will be supported for LLVM 18 only as a courtesy to help large
code bases migrate over to the Standard behavior.
---------
Co-authored-by: Bogdan Graur <bgraur@google.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This patch brings std::ios_base::noreplace from P2467R1 to libc++.
This requires compiling the shared library in C++23 mode since otherwise
fstream::open(...) doesn't know about the new flag.
Differential Revision: https://reviews.llvm.org/D137640
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
1. Instead of using individual "boolean" macros, have an "enum" macro
`_LIBCPP_HARDENING_MODE`. This avoids issues with macros being
mutually exclusive and makes overriding the hardening mode within a TU
more straightforward.
2. Rename the safe mode to debug-lite.
This brings the code in line with the RFC:
https://discourse.llvm.org/t/rfc-hardening-in-libc/73925Fixes#65101
This patch implements `std::basic_syncbuf` and `std::basic_osyncstream` as specified in paper p0053r7. ~~For ease of reviewing I am submitting this patch before submitting a patch for `std::basic_osyncstream`. ~~
~~Please note, this patch is not 100% complete. I plan on adding more tests (see comments), specifically I plan on adding tests for multithreading and synchronization.~~
Edit: I decided that it would be far easier for me to keep track of this and make changes that affect both `std::basic_syncbuf` and `std::basic_osyncstream` if both were in one patch.
The patch was originally written by @zoecarver
Implements
- P0053R7 - C++ Synchronized Buffered Ostream
- LWG-3127 basic_osyncstream::rdbuf needs a const_cast
- LWG-3334 basic_osyncstream move assignment and destruction calls basic_syncbuf::emit() twice
- LWG-3570 basic_osyncstream::emit should be an unformatted output function
- LWG-3867 Should std::basic_osyncstream's move assignment operator be noexcept?
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D67086
According to https://developer.apple.com/support/xcode/, quite a few of
our availability macros don't do anything anymore, so we might as well
remove them to clean up the code a bit.
This allows smaller allocations to occur, closer to the actual
std::string's required size. This is particularly effective in
decreasing the allocation size upon initial construction (where
__recommend is called to determine the size).
Although the memory savings per-string are never more than 8 bytes per
string initially, this quickly adds up. And has lead to not insigficant
memory savings at Google.
Unfortunately, this change is ABI breaking because it changes the value
returned by max_size. So it has to be guarded.
To allow for a smoother transition, keep the safe mode working as is in
the LLVM 18 release (the first release that aims to make hardening
available), then deprecate it in LLVM 19.
This patch removes the non compliant constructor of std::future_error
and adds the standards compliant constructor in C++17 instead.
Note that we can't support the constructor as an extension in all
standard modes because it uses delegating constructors, which require
C++11. We could in theory support the constructor as an extension in
C++11 and C++14 only, however I believe it is acceptable not to do that
since I expect the breakage from this patch will be minimal.
If it turns out that more code than we expect is broken by this, we can
reconsider that decision.
This was found during D99515.
Differential Revision: https://reviews.llvm.org/D99567
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This is useful when trying to run multiple tests with different
arguments to the executor script. This is needed in my case since I
do not know the correct ssh connection arguments when building libc++.
The testing script I have spawns multiple QEMU instances that listen on
a given port on localhost and runs lit with the --num-shards/--run-shard
argument. In order to connect each shard to the right QEMU instances I
need to customize the arguments passed to ssh.py (--extra-ssh-args and
--extra-scp-args) but can't do this at configure time since the target
port is only known when running the tests but not when calling CMake.
This change allows me to pass `executor=ssh.py <args>` to lit once I
know
the right hostname/port for running the tests.
This also deprecates the `LIB{CXX,CXXABI,UNWIND}_EXECUTOR` CMake
variable
as the same can be achieved by adding `executor=...` to the
`LIB{CXX,CXXABI,UNWIND}_TEST_PARAMS` variable.
Notice that because Holder<Incomplete> is _possible_ to complete, but
_unsafe_ to complete, that means that Holder<Incomplete>* is basically
not an iterator and it's not even safe to ask if
input_iterator<Holder<Incomplete>*> because that _will_ necessarily
complete the type. So it's totally expected that we still cannot safely
ask e.g.
static_assert(std::indirect_unary_predicate<bool(&)(Holder<Incomplete>&),
Holder<Incomplete>*>);
or even
static_assert(!std::indirect_unary_predicate<int, Holder<Incomplete>*>);
This was originally uploaded as https://reviews.llvm.org/D119029 and I
picked it up here as part of the Github PR transition.
Co-authored-by: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
This partially reverts commit e30a148b098, which removed the base
template for std::char_traits. That base template had been marked as
deprecated since LLVM 16 and we were planning to remove it in LLVM 18.
However, as explained in the post-commit comments in
https://reviews.llvm.org/D157058, the deprecation mechanism didn't work
as expected. Basically, the deprecation warnings were never shown to
users since libc++ headers are system headers and Clang doesn't show
warnings in system headers.
As a result, this removal came with basically no lead time as far as
users are concerned, which is a poor experience. For this reason, I am
re-introducing the deprecated char_traits specialization until we have a
proper way of phasing it out in a way that is not a surprise for users.
The safe mode is in-between the hardened and the debug modes, extending
the checks contained in the hardened mode with certain checks that are
relatively cheap and prevent common sources of errors but aren't
security-critical. Thus, the safe mode trades off some performance for
a wider set of checks, but unlike the debug mode, it can still be used
in production.
Differential Revision: https://reviews.llvm.org/D158823
