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
It makes the most sense to test with Clang ToT by default since that's
exactly what we're trying to QA: that libc++ works with whatever compiler
we're going to release next.
The compiler support policy mentions that we support Clang 11 and 12, so
we should test those. We already test on Clang 12, but I'll add testers
for Clang 11 once the new Docker image is in use on all the builders.
This is the first of a few commits that update the CI to match the
recently officialized compiler support policy. I'm staging those
changes to try and keep the CI green at all times, accounting how
builders refresh their Docker image.
I'm not sure what that gains us, and it creates a problem when
trying to run the tests against libc++ with a custom install name
dir (e.g. /usr/lib), since the library that we link against (in
the build tree) will advertise itself as /usr/lib/libc++.dylib,
so we end up linking against the system dylib at runtime.
Differential Revision: https://reviews.llvm.org/D105499
This patch overhauls the documentation around building libc++
for vendors, and using libc++ for end-users. It also:
- Removes mention of the standalone build, which we've been trying to
get rid of for a long time.
- Removes mention of using a local ABI installation, which we don't do
and is documented as "not recommended".
- Removes mention of the separate libc++filesystem.a library, which isn't
relevant anymore since filesystem support is in the main library.
- Adds mention of the GDB pretty printers and how to use them.
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
The runtimes build has assertions enabled, which is necessary to catch
some of the modules-related issues we've been seeing recently. This
patch enables testing with modules in the runtimes build so as to cover
those cases.
In the future, a better solution would be to systematically use versions
of Clang that have assertions enabled. However, the Clangs we release
currently don't have assertions enabled by default, which causes a
challenge for the CI (we could try to build our own Clang from ToT with
assertions in the CI, but that poses some problems).
Differential Revision: https://reviews.llvm.org/D104252
I'm adding the job as a soft-fail for now, but once all the tests have
been fixed to work on it, we'll switch over from GCC 10 to GCC 11 and
remove the soft-fail.
Differential Revision: https://reviews.llvm.org/D103116
Eventually, this should become the default way of running the tests.
For now, only move a few CI nodes to it, and keep a node that runs the
legacy configuration.
Differential Revision: https://reviews.llvm.org/D97565
This resolves issues when the CMake in use on the host is too old to
configure libc++ properly, but Xcode has a sufficiently recent version.
It is technically possible for the reverse issue to happen, where the
Xcode version would be too old and the user-installed version would be
better, however in the context of our build bots, we use AppleClang on
Apple platforms, and the CMake shipped with Xcode should work with the
AppleClang shipped alongside that Xcode.
Differential Revision: https://reviews.llvm.org/D102083
Jobs that test with a more recent standard version run more tests, so
they take longer. We'll decrease the average latency by running them
first instead of last.
Louis Dionne