Now that we've branched for the LLVM 14 release, our support window
moves to clang-13 and clang-14. Similarly, AppleClang 13 has been
released for some time now, so that should be the oldest compiler
we support, per our policy.
A possible follow-up would be to remove _LIBCPP_HAS_NO_CONCEPTS, since
I don't think we support any compiler that doesn't support concepts
anymore.
Differential Revision: https://reviews.llvm.org/D118831
libc++abi should be responsible for installing its own headers, it
doesn't make sense for libc++ to be responsible for it.
Differential Revision: https://reviews.llvm.org/D101458
Some jobs might not produce those, but it makes the blocks easier to
copy-paste and makes sure that if a job does produce an ABI list, it
will be updloaded in the artifacts.
Differential Revision: https://reviews.llvm.org/D120056
This patch upstreams some changes we've made internally to how we're
building the libc++ dylib on Apple platforms. The goal is still to
eventually get rid of `apple-install-libcxx.sh` entirely and have a
proper way to mirror what we do internally with just the normal CMake
configuration.
Differential Revision: https://reviews.llvm.org/D118912
This change will make it possible to track exported symbols in more
configurations, notably the Apple system one, where we disable incomplete
features and the debug mode. Also, as a fly-by fix, shorten the name for
whether new is in libc++ or not.
Differential Revision: https://reviews.llvm.org/D119764
This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.
As a fly-by, fix missing availability annotations on optional's
monadic operations.
Differential Revision: https://reviews.llvm.org/D119840
We added one for libc++ recently, and this patch adds one for libc++abi.
Also, as a fly-by fix, include older libunwind dylibs in the testing of
libc++ and libc++abi, which fixes some issues related to running
back-deployment tests on newer systems.
Differential Revision: https://reviews.llvm.org/D119466
Standalone build have been deprecated for some time now, so this
commit removes support for those builds entirely from libc++, libc++abi
and libunwind.
This, along with the removal of other legacy ways to build, will allow
for major build system simplifications.
Differential Revision: https://reviews.llvm.org/D119255
This testing configuration links tests against one libc++ shared library,
but runs them against another libc++ shared library. This makes sure that
we can build applications against the libc++ provided in a recent SDK and
back-deploy them to platforms containing older libc++ dylibs.
It also switches the Apple CI script to using that new configuration
instead of the legacy one.
Differential Revision: https://reviews.llvm.org/D119195
Many CI runs are very similar in nature. Let's put them into groups for a better overview
Reviewed By: ldionne, #libc
Spies: libcxx-commits, arichardson, mstorsjo
Differential Revision: https://reviews.llvm.org/D119059
This patch makes the uncontrovertial changes to the pipeline.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D119041
To ensure a smooth transition without breaking CI, we should use explicitly
versioned Clangs in the CI jobs definition instead, since that's a change
we can actually test in the CI.
So instead of bumping the compiler version from the Docker image, use
the same version as before by default, and we can bump it from the CI
job definition once all the nodes are running the new image.
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
The documentation CI job is very cheap, so we can afford to keep it
around even with reduced capacity. This commit fixes the documentation
(which had an invalid reference in it) and re-enables that CI step.
Differential Revision: https://reviews.llvm.org/D116897
There is an ongoing CI outage with our Linux nodes, so I temporarily
set up a couple of nodes. These nodes will be much slower than the
usual ones and there's only a few of them, so I am temporarily disabling
most of our CI to keep things working.
The paths to the compiler and to the python executable may need to
be quoted (if they're installed into e.g. C:\Program Files).
All testing commands that are executed expect a gcc compatible command
line interface, while clang-cl uses different command line options.
In the original testing config, if the chosen compiler was clang-cl, it
was replaced with clang++ by looking for such an executable in the path.
For the new from-scratch test configs, I instead chose to add
"--driver-mode=g++" to flags - invoking "clang-cl --driver-mode=g++"
has the same effect as invoking "clang++", without needing to run any
heuristics for picking a different compiler executable.
Differential Revision: https://reviews.llvm.org/D111202
This is similar to the existing setting LIBCXX_ABI_DEFINES, with
the difference that this also allows setting other defines than
ones that start with "_LIBCPP_ABI_", and allows setting defines
to a specific value.
This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two
CI configurations.
Differential Revision: https://reviews.llvm.org/D116109
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.
As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.
Differential Revision: https://reviews.llvm.org/D114473
When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and we would have to add all these system libraries manually, which is
not portable and error prone. Instead, stop using `-nodefaultlibs` so
that we get the libraries added by default by the compiler.
The only caveat with this approach is that we are now relying on the
fact that `-L <path-to-local-libunwind>` will cause the just built
libunwind to be selected before the system implementation (either of
libunwind or libgcc_s.so), which is somewhat fragile.
This patch also turns the 32 bit multilib build into a soft failure
since we are in the process of removing it anyway, see D114473 for
details. This patch is incompatible with the 32 bit multilib build
because Ubuntu does not provide a proper libstdc++ for 32 bits, and
that is required when running with sanitizers enabled.
Differential Revision: https://reviews.llvm.org/D114385
Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.
Add an XFAIL for a recently added test that fails in the MinGW DLL
configuration (with an explanation of what's causing the failure).
Differential Revision: https://reviews.llvm.org/D112215
We are trying to remove duplication of third-party code in
https://reviews.llvm.org/D112012, which will move the Google
Benchmark code outside of the `libcxx/` directory. That breaks
running the benchmarks in the Standalone build. Since we have
deprecated the Standalone build anyway, this patch just removes
support for the benchmark in Standalone mode until we remove that
mode entirely.
Differential Revision: https://reviews.llvm.org/D113503
Instead of hard-coding the target for our CI nodes, use the default
compiler triple. Also, allow building compiler-rt for the single
specified triple in case we're running on Darwin (otherwise, the
bootstrapping build complains).
Differential Revision: https://reviews.llvm.org/D113683
and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path.
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D113403
This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111359
[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.
Reviewed By: #libc, ldionne, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113186
Per our support plan we should now support Clang 12 and 13. Adjust the
documentation and the CI runners. The change indirectly moves the main
CI runners to use the Clang 14 nightly builds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112360
Running tests for libunwind is a lot simpler than running tests for
libc++, so a simple Lit config file is sufficient. The benefit is that
we disentangle the libunwind test configuration from the libc++ and
libc++abi test configuration. The setup was too complicated, which led
to some bugs (notably we were running against the system libunwind on
Apple platforms).
Differential Revision: https://reviews.llvm.org/D111664
This commit makes the new "runtimes" build (with <monorepo>/runtimes as
the root of the CMake invocation) the default way of building libc++.
The other supported way of building libc++ is the "bootstrapping" build,
where `<monorepo>/llvm` is used as the root of the CMake invocation.
All other ways of building libc++ are deprecated effective immediately.
There should be no use-case for building libc++ that isn't supported by
one of these two builds, and the two new builds work on all environments
and are lightweight. They will also make it possible to greatly simplify
the build infrastructure of the runtimes, which is currently way too
convoluted.
Differential Revision: https://reviews.llvm.org/D111356
That script is what we (need to) use to build libc++ for the system
configuration, so that's what we should test against. At some point
we may be able to fold all of that logic into the CMake build, and
when that happens the CI can go back to running CMake directly.
As a fly-by fix, stop mentioning x86_64 in the names of the Apple
jobs since they are not truly tied to any architecture.
Differential Revision: https://reviews.llvm.org/D111865
This initial change adds the AIX configuration to run-buildbot, an AIX
CMake cache file, and appropriate compiler and linker flags for testing
AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations
can be built by setting `OBJECT_MODE` in the build environment (as is
typical for AIX).
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D111244
I came across an issue where since we build the library for Apple with
the install name directory being /usr/lib, which means that if we don't
run the tests with DYLD_LIBRARY_PATH, we'll end up loading the
system-provided libc++abi when running the tests. That wreaks havoc.
Instead of fixing it in the legacy config file, this commit introduces
an Apple libc++abi config file that does the right thing.
Differential Revision: https://reviews.llvm.org/D111279
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.
Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.
Differential Revision: https://reviews.llvm.org/D111265
It is not used anywhere anymore since we're using the new runtimes build
in <monorepo>/runtimes now, so we can remove all traces of this build.
Differential Revision: https://reviews.llvm.org/D111351
When we recently started using DYLD_LIBRARY_PATH to run the test suite
on the Apple/System configuration of the library, the -fno-exceptions
variant started failing.
It started failing because under that configuration, libc++abi.dylib
doesn't provide support for exceptions. For example, it doesn't provide
some symbols such as ___gxx_personality_v0. Now, the problem is that
when the test suite is run with DYLD_LIBRARY_PATH, /usr/lib/libobjc.dylib
uses the just-built libc++abi.dylib, which doesn't support exceptions,
and we end up with an unresolved reference to ___gxx_personality_v0.
Previously, using -Wl,-rpath,path/to/lib, we would be loading both
/usr/lib/libc++abi.dylib and <just-built>/lib/libc++abi.dylib.
/usr/lib/libobjc.dylib would use the system libc++abi.dylib, which
contains support for exceptions, and the tests would be using the
just-built one, which doesn't.
Disentangling that led me to believe that we shouldn't try to test this
configuration where libc++/libc++abi are built as system libraries, but
where they don't support exceptions, since that just doesn't make any
sense. Doing so is like trying to build libc++/libc++abi and test it as
a system library after performing an ABI break -- of course nothing is
going to work.
For that reason, I am removing this configuration. Note that we could
still test the library on macOS without exceptions if we wanted, only
we wouldn't be building it as a system library. This patch doesn't add
that because we already have a -fno-exceptions CI job on Linux.
Differential Revision: https://reviews.llvm.org/D111349
We should arguably have always been doing that. The state of libunwind
is quite sad, so this commit adds several XFAILs to make the CI pass.
We need to investigate why so many tests are not passing in some
configurations, but I'll defer that to folks who actually work on
libunwind for lack of bandwidth.
Differential Revision: https://reviews.llvm.org/D110872
Apple's libc++ has a few differences with the LLVM libc++, and it is
necessary to use a custom configuration file to test it properly.
Differential Revision: https://reviews.llvm.org/D110777
To reduce confusion, this commit makes sure that the name of the testing
configurations match the convention used for the stdlib= Lit parameter,
since those effectively correspond to each other.
The Runtimes build is by far our longest CI configuration, so it makes
sense to run it earlier during CI. For consistency, move all the other
jobs from that "section" too.
Once all the bots are passing with from-scratch configs, we can attempt
to make the from-scratch config the default configuration.
Differential Revision: https://reviews.llvm.org/D103417
It was added after we changed the way the CI jobs are run, in particular
how they are pinned down to Linux instances only. As a result, the job
would sometimes run on Mac machines, which we're trying to keep only for
jobs that absolutely need it due to capacity concerns.
This option is used to select between the format headers output column
width option. This option should be independent of the locale setting.
It's encouraged to default to Unicode unless the platform doesn't offer
that option.
[format.string.std]/10
```
For the purposes of width computation, a string is assumed to be in a
locale-independent, implementation-defined encoding. Implementations
should use a Unicode encoding on platforms capable of displaying Unicode
```
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103379
We just had a case where a build bot stalled in an infinite loop during
testing, and the whole pipeline got stuck. To avoid that from happening
in the future, use a timeout on BuildKite jobs.
Differential Revision: https://reviews.llvm.org/D107765
The Generated output CI job only tests for modified files. This job
should also fail the generated output contains new files.
It would be possible to test modified and untracked files in one
execution of `git ls-files`. However the diff is stored as an artifact
so the execution of `git diff` would still be required.
Discussion: Would it be better to do `git ls-files -om` and remove the
excution of
`! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false` ?
(Obviously then the name `generated_output.untracked` should change to
something like `generated_output.status`)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D106534
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).
Differential Revision: https://reviews.llvm.org/D105936
As we automate more and more things in the library, it becomes useful for
contributors to have a single target for running all the automation as
part of their workflow. This commit adds a new `libcxx-generate-files`
target that should re-generate all the auto-generated files in the library.
As a fly-by, I also revamped the documentation on Contributing to account
for this new target and present it as a bullet list of things to check
before committing. I also added a few things that are often overlooked
to that list, such as updating the synopsis and the status files.
Differential Revision: https://reviews.llvm.org/D106067
This is what ffccf96e90 should have enabled, however the symlink
in the Docker image was not pointing to the right compiler, so we were
testing with Clang 12 instead of ToT.
For reasons unknown, the build is now using compilers
from /usr/bin instead of /usr/local/bin which is where
we have our clang-12 aliases placed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105704
Louis Dionne