At this point, every supported compiler that claims a -std=c++17 mode
should also support `if constexpr`. This was an issue for GCC 5
and GCC 6, but hasn't been an issue since GCC 7. (Our current
minimum supported GCC version, IIUC, is GCC 10 or 11.)
Differential Revision: https://reviews.llvm.org/D113348
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
`utils/generate_feature_test_macro_components.py` uses the wrong
indentation. `:name: feature-status-table :widths: auto` is rendered as
text instead of being used by Sphinx to render the table properly.
This fixes the identation in the souce and updates the generated output.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D112251
This temporary FIXME really belongs to the testing config, not to the
specific CMake cache that enables that configuration.
Differential Revision: https://reviews.llvm.org/D112031
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
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.
In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.
The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.
But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.
This is a re-application of 9892d1644f, which was reverted in 138dc27186
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.
Differential Revision: https://reviews.llvm.org/D110736
Reduce code duplication by sharing most of the test suite setup across
the different from-scratch configs.
Differential Revision: https://reviews.llvm.org/D111196
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
This is to simplify an upcoming change where we distinguish between
flavors of libc++ by adding an apple-libc++ Lit feature.
Differential Revision: https://reviews.llvm.org/D110870
This reverts part of commit b82683b2eb.
I hadn't intended to remove the `// -*- C++ -*-` comment line
from `libcxx/include/version`, only from the generated tests.
Thanks to Raul Tambre for the catch.
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
This reverts commit 9f641c96cb.
The "python" command in gdb uses the python gdb is linked to,
not what "python" would give you if you used it directly in the shell.
As of e9564c3698, libcxx/gdb/gdb_pretty_printer_test.sh.cpp
fails locally for me because the REQUIRES check for host-has-gdb-with-python
uses python, which for me expands to python 2.7.18. This failure does not seem
to be caught on any upstream builders, potentially because they don't have gdb,
python, or a version of python that makes the test UNSUPPORTED (like python3).
This updates the check to use the python specified by the build (which should
be the python that runs this code), rather than just python.
Differential Revision: https://reviews.llvm.org/D110887
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.
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.
In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.
The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.
But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.
Differential Revision: https://reviews.llvm.org/D110736
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.
Before this patch, we had features named 'libc++', 'libstdc++' and
'msvc' to describe the three implementations that use our test suite.
This patch renames them to 'stdlib=libc++', 'stdlib=libstdc++', etc
to avoid confusion between MSVC's STL and the MSVC compiler (or Clang
in MSVC mode).
Furthermore, this prepares the terrain for adding support for additional
"implementations" to the test suite. Basically, I'd like to be able to
treat Apple's libc++ differently from LLVM's libc++ for the purpose of
testing, because those effectively behave in different ways in some aspects.
This reverts commit 0c2a454845.
This was my mistake. When gdb can find its data directory it'll
import it automatically. If it can't (like when you're using a
version from a build folder) you need to give it the data
directory path.
We're safe to assume gdb is installed for testing purposes
so it'll import it for us.
I found this after upgrading from Ubuntu bionic (gdb 8.1.1) to
Focal (gdb 9.2). (where this test fails, but that's for a
different patch)
9.2 allows you to set breakpoint commands from
Python, which was added in 8.3.
(bintutils a913fffbdee21fdd50e8de0596358be425775678
"Allow breakpoint commands to be set from Python")
The reason this test never failed before was because it did so
silently. "source <python file>" doesn't fail even if that script
raises an Exception.
To fix this extend the gdb lit feature to check that:
* gdb exists
* has Python support
* allows you to set breakpoint commands
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110334
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.
Arthur O'Dwyer