The goal was to add coverage for back-deployment over the filesystem
library, but it was added in macOS 10.15, not 10.14.
Differential Revision: https://reviews.llvm.org/D92937
It adds coverage for back-deploying to a system that contains the
filesystem library, which 10.9 (currently our only back-deployment
target in the CI) does not have.
Differential Revision: https://reviews.llvm.org/D92794
By encoding ABI-affecting properties in the name of the ABI list, it
makes it clear when an ABI list test should or should not be available,
and what results we should expect.
Note that we clearly don't encode all ABI-affecting parameters in the
name right now -- I just ported over what we supported in the code that
was there previously. As we encounter configurations that we wish to
support but produce different ABI lists, we can add those to the ABI
identifier and start supporting them.
This commit also starts checking the ABI list in the CI jobs that run
a supported configuration. Eventually, all configurations should have
a generated ABI list and the test should even run implicitly as part of
the Lit test suite.
Differential Revision: https://reviews.llvm.org/D92194
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.
At the same time, also fix some tests that were failing when back
deploying.
Differential Revision: https://reviews.llvm.org/D90869
Remove Phabricator, which isn't needed anymore since we don't report
the job results ourselves. Also, install python3-sphinx instead of
sphinx-doc, since the latter doesn't provide the sphinx-build binary.
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
Now libc++ pipeline will be triggered from the "premerge-checks" and the
combined result are going to be returned to Harbormaster.
Reviewed-by: ldionne
Differential Revision: https://reviews.llvm.org/D89113
Define all the fuzzing tests in libcxx/test/libcxx/fuzzing, and get
rid of the ad-hoc libcxx/fuzzing directory, which wasn't properly
integrated with the build system or test suite.
As a fly-by change, this also reduces the dependencies of fuzzing tests
on large library components like <iostream>, to make them work on more
platforms.
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.
Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
Some libc++ builds may want to disable support for the debug mode,
for example to reduce code size or because the current implementation
of the debug mode requires a global map. This commit adds the
LIBCXX_ENABLE_DEBUG_MODE CMake option and ties it into the test
suite.
It also adds a CI job to test this configuration going forward.
Differential Revision: https://reviews.llvm.org/D88923
The CONDUIT_TOKEN is already taken from the environment. Also, disable
reporting back to Phabricator for now until we're ready to start spamming
the results back. This still needs a bit of testing.
This commit adds basic files and scripts that are used for the Buildkite
pre-commit CI setup. This was tested to mostly work on a fork of llvm-project,
however some adjustments will have to be made as we complete the real
setup.
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.
Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.
The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
complicated, and it has been a source of bugs in the past. I have
simplified it iteratively in the past, but the complexity is still
there.
2. The deployment-target detection started failing in weird ways in
recent Clangs, breaking our CI. Instead of band-aid patching the
issue, I decided to remove the complexity altogether by using target
triples even on Apple platforms.
A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
Louis Dionne