Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library Hardening
(one particular benefit is that using the `observe` semantic makes adopting
hardening easier for projects).
(cherry picked from commit 3eee9fc2c4d1973904b1a26fa96a8c7473ef6a5e)
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library
Hardening (one particular benefit is that using the `observe` semantic
makes adopting hardening easier for projects).
Update the premerge testing system to use the LLVM-wide premerge
infrastructure. Also remove libcxx-restart-preempted-jobs.yaml, as this
should no longer be needed.
Our CI is currently having major difficulties, which causes the Stage 3
CI to basically never succeed. As a result, our macOS CI jobs have not
been running recently. This patch gates the macOS CI jobs on Stage 2
instead of Stage 3 so that they actually run sometimes.
In 0547e573c555, I introduced backdeployment testing on macOS using
Github-provided builders. This was done by basically building libc++ on
a slightly older macOS (like macOS 13) and then running against the
system library on that machine. However, that created a dependency that
libc++ must keep working on macOS 13, which doesn't support the
latest-released Xcode.
This patch solves that problem by moving the deployment testing to a
newer version of macOS which supports the latest-released version of
Xcode.
Sadly, that also reduces the backdeployment coverage we have since we're
not actually testing on older OSes, but is necessary to satisfy the
documented libc++ support policy. In the future, we could improve the
situation by providing a Lit configuration that allows compiling (but
not running) all the tests, building the tests on a supported macOS, and
then shipping those tests on an older backdeployment target in order to
run them against the system library. Since that requires significant
engineering, this isn't done at this time.
In recent versions of Clang, using -std=c++20 (and later) implies LSV
when compiling with modules. This change resulted in making our LSV job
redundant with the regular modules job, which uses the latest Standard.
This patch increases the coverage of our CI without increasing its cost
by pinning the LSV job to use C++17, which normally doesn't use LSV. A
related question is whether we should add coverage for non-LSV builds
using Clang modules.
This patch has pins actions in the libc Github workflows. Hash pinning
is a best practice as it ensures we are getting an exact action version,
which can help with reproducibility/reliability. It additionally
alleviates security concerns as an attacker can modify release assets,
potentially giving them access to tokens in privileged workflows.
This also fixes test failures in the clang-cl build configs that started
a couple days ago. It seems like the failures were triggered by an update
to the base image on the Github provided runners.
There were failures in test/libcxx/system_reserved_names.gen.py, due to
an issue in an Clang intrinsics header (avx512fp16intrin.h); this issue
was observed and fixed for Clang 19 in 6f04f46927c. The test does
#define A SYSTEM_RESERVED_NAME
which clashes with a parameter with the name `A` in that header.
By upgrading the toolchain to Clang 19, we get fixed version of this
intrinsics header.
Also update the llvm-mingw toolchains to a version with Clang 19.1.7.
I've recently noticed that our CI is bottlenecked around platforms on
which we don't have a lot of capacity like macOS (mostly) and Windows.
To try to alleviate that, this patch moves the macOS builds and the
Windows builds further down the pipeline so that they will get triggered
less often (if an earlier job fails).
This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public
header look like this:
```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```
In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.
After a recent Github Actions runner policy change [1], the version of
Xcode included in the macos-14 image went from Xcode 16 to Xcode 15,
breaking our build bots.
This moves the bots to the macos 15 (public preview) image, which
contains Xcode 16.
Also, adjust an UNSUPPORTED annotation that was incorrectly targeting
macos 13.7 when it should have been targeting a version of AppleClang.
[1]: https://github.com/actions/runner-images/issues/10703
Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
This change attempts to shift the libc++ builders over to new backend
infrastructure that allows running an arbitrary container for the
libc++ job.
This has been a long time in the making, and support from github
and gke is finally at the point where it's possible (hopefully).
This change should also demonstrate another important property:
No Downtime Upgrades.
If this goes well, we'll be able to test the upgrade as a part
of the PR process, and then commiting it to main should (ideally)
not break anything.
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
When bringing up a new cross compiler from scratch, we build
libunwind/libcxx in a setup where the toolchain is incomplete and unable
to perform the normal linker checks; this requires a few special cases
in the CMake files.
We simulate that scenario by removing the libc++ headers, libunwind and
libc++ libraries from the installed toolchain.
We need to set CMAKE_CXX_COMPILER_WORKS since CMake fails to probe the
compiler. We need to set CMAKE_CXX_COMPILER_TARGET, since LLVM's
heuristics fail when CMake hasn't been able to probe the environment
properly. (This is normal; one has to set those options when setting up
such a toolchain from scratch.)
This adds CI coverage for these build scenarios, which otherwise seldom
are tested by some build flow (but are essential when setting up a cross
compiler from scratch).
This patch decouples macOS CI testing from BuildKite, which makes the
maintenance of macOS CI easier and more accessible to all contributors.
Right now, the macOS CI is running entirely on machines owned by the
LLVM Foundation with only a small set of contributors having direct
access to them. In particular, updating these machines is currently
a very time-consuming manual process that requires taking the machines
offline, and using Github-provided instances makes that an order of
magnitude easier.
The story for performing back-deployment testing still needs to be
figured out, so for now we are retaining some jobs under BuildKite.
Pick the latest version available in Chocolatey (18.1.6) and llvm-mingw
(20240606, which includes LLVM 18.1.7).
Also add the flag "--allow-downgrade" when installing a specific version
of LLVM. If the preinstalled version is higher than the requested one,
Chocolatey would otherwise error out when requesting installing a lower
version. This will avoid errors in the future, if the runner image comes
preinstalled with a newer version of LLVM.
(This currently seems to happen with a recent version of the GitHub
Actions runner image, version 20240610.1.0 has LLVM 18.1.6 already
preinstalled, and will error out when trying to install the 17.0.6
version that we previously requested.)
Since we have released Clang 16 is no longer actively supported. However
the FreeBSD runner is still using this, so some tests still guard
against Clang 16.
The upload-artifact@v3 action is using Node 16, which is reaching EOL.
As a result, we are getting warnings prompting us to move our jobs over
to the latest version of upload-artifact.
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.
These cause test build failures on Windows.
This reverts the following commits:
57ca74843586c9a93c425036c5538aae0a2cfa60
d06ae33ec32122bb526fb35025c1f0cf979f1090
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.
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
This patch adds a configuration of the libc++ test suite that enables
optimizations when building the tests. It also adds a new CI
configuration to exercise this on a regular basis. This is added in the
context of [1], which requires building with optimizations in order to
hit the bug.
[1]: https://github.com/llvm/llvm-project/issues/68552
The runners-32 group is broken, for reasons...
The easiest fix is to move the jobs to runners-8.
(which needs to be renamed, because they're all actually 30 core
machines)
There are a few drive-by fixes:
- Since the combination RTTI disabled and exceptions enabled do not
work, this combination is prohibited.
- A small NFC in any fixing clang-tidy.
The code in the Buildkite configuration is prepared for using the std
module. There are more fixes needed for that configuration which will be
done in a separate commit.
It seems the fail fast just doesn't strike the right balance.
It wastes too many resources, especially if a build is killed because
the machine it was running on got preempted.
Instead, we should simply not run any future jobs if a failure has
occured, while letting the already running jobs finish.
