The machine hosting these agents will be down
for maintenance June 2nd.
We (Linaro) will remove this once the agents are back online.
Differential Revision: https://reviews.llvm.org/D126688
P0798R8 "Monadic operations for std::optional" has been implemented, so
this LWG issue can be adopted.
During review it was discovered another paper bumped the macro. The
part affecting optional of this paper is done, the variant isn't. The
status page is updated to reflect the current state.
Implements
- LWG 3621 Remove feature-test macro __cpp_lib_monadic_optional
Updates status of
- P2231R1 Missing constexpr in std::optional and std::variant
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D125813
Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name libcpp-has-no-xxx
doesn't make sense.
Differential Revision: https://reviews.llvm.org/D126482
Add a warning and tweak the release note to explain that the deprecation
targets libc++, libc++abi and libuwnind as well.
Also, as a fly-by, ensure that our CI runs the legacy testing configuration
for libc++, libc++abi and libunwind. This doesn't matter too much since
it's deprecated, but we might as well test it properly.
Differential Revision: https://reviews.llvm.org/D126478
Start testing Apple backdeployment with older libunwinds, and stop
explicitly specifying the libunwind testing config, since it is
already selected correctly by default.
Differential Revision: https://reviews.llvm.org/D126470
Once we move off entirely from the legacy testing framework, this will
allow removing a bunch of code.
Differential Revision: https://reviews.llvm.org/D126303
This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.
Differential Revision: https://reviews.llvm.org/D125331
Also, add a CI job that tests this configuration. The exact configuration
is that we build a shared libc++ and merge objects for the ABI library
and the unwinder library into it.
Differential Revision: https://reviews.llvm.org/D125903
This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.
Differential Revision: https://reviews.llvm.org/D125393
For example, we used to trigger CI even for commits that touched a file
whose path contained 'cmake', even if it's not the root cmake directory.
Fix that.
This patch overhauls how we pick up the ABI library. Instead of setting
ad-hoc flags, it creates interface targets that can be linked against by
the rest of the build, which is easier to follow and extend to support
new ABI libraries.
This is intended to be a NFC change, however there are some additional
simplifications and improvements we can make in the future that would
require a slight behavior change.
Differential Revision: https://reviews.llvm.org/D120727
On targets without unistd.h or sys/wait.h (such as bare metal targets)
any test that uses check_assertion.h will fail, so add
REQUIRES: has-unix-headers to them and autodetect whether we have
these headers or not.
These tests currently have unsupported on windows, but that's exactly
because windows doesn't have these headers so we can remove the
specific check for windows.
Differential Revision: https://reviews.llvm.org/D124623
Adding a mingw based config is easy in the current CI environment
(where we can just choose the different target by calling
`i686-w64-mingw32-clang`), while adding a clang-cl based config would
require setting up different environment variables pointing to the
i386 library directory.
Just adding one config (DLL) instead of exhaustively testing both
(DLL and static) as very few tests would differ in practice, to keep
the CI load reasonable.
Differential Revision: https://reviews.llvm.org/D124991
We are considering to make -fsanitize-memory-param-retval enabled by default so probably this patch is unnneded.
Reviewed By: #libc, EricWF
Differential Revision: https://reviews.llvm.org/D123979
This makes the code a bit simpler and (I think) removes the undefined behaviour from the normal string layout.
Reviewed By: ldionne, Mordante, #libc
Spies: labath, dblaikie, JDevlieghere, krytarowski, jgorbe, jingham, saugustine, arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123580
If a single test has been running for more than 20 minutes on a CI node,
something is wrong and it should time-out instead of running until the
node potentially times out itself.
Differential Revision: https://reviews.llvm.org/D114896
This supersedes and incoroporates content from both D108906 and D54966,
and also some original content.
Co-Authored-by: Marshall Clow <mclow.lists@gmail.com>
Co-Authored-by: Gonzalo Brito Gadeschi
Differential Revision: https://reviews.llvm.org/D118938
This change is done to see whether all platforms have a CI with the
Japanese locale installed.
This wires in the locale in the tests and uses it in one test. This is
a preparation for the tests of the chrono formatters.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122738
There are no such markings left - all of them have been fixed or
analyzed.
This closes llvm.org/PR32730 (github issue #32077).
Differential Revision: https://reviews.llvm.org/D123145
This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.
Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D62641
Note that `generate_assertion_tests.py` will be renamed to
`generate_header_tests.py` separately to facilitate change tracking.
Differential Revision: https://reviews.llvm.org/D123000
The alternative outputs of std::put_time and std::strftime are the
easiest to test with the Japanese locale. This is a preparation for the
tests of the chrono formatters.
Note since it takes a while before the Docker file changes propagate to
the build nodes the verification of the locale is done in a separate
patch.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122736
It seems to have been added back in 761e42fa3d for Clang to use it,
however it seems to have never been used for that purpose, so it is
probably fine to remove it.
Differential Revision: https://reviews.llvm.org/D122330
For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnoticed. Thanks to @EricWF for the catch.
Differential Revision: https://reviews.llvm.org/D120851
This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
This patch makes it possible to pass a CMake option to one of the runtimes
for all targets being built. Basically, any option that starts with the
name of a runtime project being built will be forwarded as-is to the
sub-build. This is useful for customizing a sub-build for all targets.
Differential Revision: https://reviews.llvm.org/D121822
It turns out that we had never been enabling it anyways, since the
LIBCXX_TEST_PARAMS parameter was not being passed from the bootstrapping
build to the libc++ and libc++abi builds. Furthermore, it looks like the
per-target include directories used by the bootstrapping build by default
are incompatible with our current modulemap, since __config_site doesn't
live in the directory that our modulemap claims.
This disables modules in our bootstrapping CI job to unblock D121822,
but we should work on fixing the underlying issue once we're able to
pass those configuration options to our bootstrapping build.
We've been meaning to remove support for the legacy testing configuration
for a long time. This patch switches the default from the legacy config
to the appropriate new-style configuration based on a few hints.
We've been running with the new-style configuration for more than a year
in our CI, however it's possible that this will uncover issues with some
users that run the tests on platforms that we don't support yet with the
new-style configs. Unfortunately, there is no way to know about it other
than to land this patch and see whether anything breaks.
Differential Revision: https://reviews.llvm.org/D121632
This reverts commit 406d418c0c.
Our regular bots are now using clang-13. The previous set will remain
online for a while to check reviews that haven't rebased to include
this change yet.
Differential Revision: https://reviews.llvm.org/D121894
In the new-style testing configurations, we were hardcoding paths to the
`include` and `lib` directories, which was incorrect but always went
unnoticed because the hardcoded values always happened to match the
actual value.
When using new-style configs with the bootstrapping build, this falls
appart -- and we never noticed this because the bootstrapping build was
still using old style configs.
This patch removes the %{install} substitution, which makes it too
tempting to hardcode installation paths, and it also switches the
bootstrapping build to actually using new-style configs like we
always intended to do.
Differential Revision: https://reviews.llvm.org/D121700
This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.
After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.
Differential Revision: https://reviews.llvm.org/D120684
Prior to this patch, there was no distinction between tests that check
basic assertions and tests that check full-fledged iterator debugging
assertions. Both were disabled when support for the debug mode is not
provided in the dylib, which is stronger than it needs to be.
Furthermore, all of the tests using "debug_macros.h" that contain more
than one assertion in them were broken -- any code after the first
assertion would never be executed.
This patch refactors all of our assertion-related tests to:
1. Be enabled whenever they can, i.e. basic assertions tests are run
even when the debug mode is disabled.
2. Use the superior `check_assertion.h` (previously `debug_mode_helper.h`)
instead of `debug_macros.h`, which allows multiple assertions in the
same program.
3. Coalesce some tests into the same file to make them more readable.
4. Use consistent naming for test files -- no more db{1,2,3,...,10} tests.
This is a large but mostly mechanical patch.
Differential Revision: https://reviews.llvm.org/D121462
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
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
Those older versions used a different monetary decimal separator.
To avoid unnecessary churn to support that, just XFAIL the test
on those older versions. (Up until
df1e43c496, the whole test was XFAILed
on all versions of glibc.)
Differential Revision: https://reviews.llvm.org/D120979
As a fly-by fix, enable the complexity-changing assertions in __debug_less
only when the full debug mode is enabled, since debugging level 0 is usually
understood to only contain basic assertions that do not change the complexity
of algorithms.
Differential Revision: https://reviews.llvm.org/D121129
Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normally get if we included
the headers as user headers.
The goal of the test suite is normally to mirror as closely as possible
how users would use the library. Technically, this change goes against
that philosophy, since users should be using `-isystem` (if they ever
need to specify the libc++ path explicitly, which should be a rare
occurence). However, I believe fishing out additional warnings from
the headers provides more value, hence this change. Ideally, we'd be
able to still use `-isystem`, but instruct Clang to still emit warnings
from the libc++ headers (e.g. we could tell Clang to emit warnings in
any file inside `<...>/usr/include/c++/v1`).
Reviewed By: #libc, ldionne, #libc_abi
Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D118616
As part of https://reviews.llvm.org/D119036
(506cf6dc04), `-DNOMINMAX` was
dropped from the Windows CI configurations, replaced with a
block with `_LIBCPP_PUSH_MACROS`, `#include <__undef_macros>`
and `_LIBCPP_POP_MACROS` (and
`ADDITIONAL_COMPILE_FLAGS: -DNOMINMAX` left in two tests).
However, this workaround breaks the running the libc++ tests
against a different C++ standard library than libc++, as those
macros and that header are libc++ internals.
Therefore, reinstate `-DNOMINMAX` for clang-cl configurations
and remove the libc++ specific bits in filesystem_test_helper.h.
Differential Revision: https://reviews.llvm.org/D120478
These tests are hit hard by a bug that is fixed in a newer version
of UCRT. Add a test for the specific bug, and XFAIL the tests if
that bug is present (as it is in CI).
Split out hex formatting of floats to separate test files, that
are excluded with `XFAIL: msvc`. (Based on reading the C standard for
printf formatting, it seems like this isn't necessarily a proper bug
in printf, but just a case of differing optional behaviour.)
Differential Revision: https://reviews.llvm.org/D120022
Add an explicit LIBCXX_CXX_ABI=system-libcxxabi option for linking to
system-installed libc++abi. This fixes the ability to link against one
when building libcxx via the runtimes build, as otherwise the build
system insists on linking into in-tree targets.
Differential Revision: https://reviews.llvm.org/D119539
This commit reverts 5aaefa51 (and also partly 7f285f48e7 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.
Differential Revision: https://reviews.llvm.org/D120683
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
A merge conflict in D106124 accidentally reverted this part of
b82683b2e/D110794.
> 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.
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
Differential Revision: https://reviews.llvm.org/D106124
Since Windows 10 version 1803 (10.0.17134.0) (or Windows Server 2019),
the Windows Universal C Runtime (UCRT) actually does support UTF-8
locales - they're available e.g. via the same names as commonly on Unices,
e.g. "en_US.UTF-8".
The UTF-8 locale support unfortunately has a bug which breaks a couple
tests that were passing previously. That bug is fixed in the very
latest version of the UCRT (in UCRT 10.0.20348.0, available in Windows
11 or Windows Server 2022), so it will get resolved at some point
eventually, provided that the CI environment does get upgraded to a
newer version of Windows Server.
While the net number of xfailed/passing tests in this patch is a loss,
this does allow fixing a lot more locale tests properly for Windows
in later patches.
Intentionally not touching the ISO-8859-1/2 locales used for testing;
they're not detected and tested/used right now, and fixing that up
is another project.
Differential Revision: https://reviews.llvm.org/D119930
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 is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.
Differential Revision: https://reviews.llvm.org/D119769
I'm trying to get libc++ to the point of being able to run clang-tidy. This is a PR to see if clang-tidy is happy with all the CI configs.
Reviewed By: Quuxplusone, ldionne, #libc
Spies: mgorny, aheejin, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D117174
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
`<filesystem>` header has been around for a while now, so we can safely remove
`<experimental/filesystem>` header. `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM`
suggests we were going to remove `<experimental/filesystem>` in llvm 11 release,
but we never did. So, remove the experimental header now, its associated tests,
and the `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM` macro.
Differential Revision: https://reviews.llvm.org/D119603
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
Previously, _LIBCPP_ABI_UNSTABLE would be used interchangeably with
_LIBCPP_ABI_VERSION >= 2. This was confusing and creating unnecessary
complexity.
This patch removes _LIBCPP_ABI_UNSTABLE -- instead, the LIBCXX_ABI_UNSTABLE
CMake option will result in the LIBCXX_ABI_VERSION being set to '2', the
current unstable ABI. As a result, in the code, we only have _LIBCPP_ABI_VERSION
to check in order to query the current ABI version.
As a fly-by, this also defines the ABI namespace during CMake configuration
to reduce complexity in __config. I believe it was previously done this
way because we used to try to use __config_site as seldom as possible.
Now that we always ship a __config_site, it doesn't really matter and
I think being explicit about how the library is configured in the __config_site
is actually a feature.
Differential Revision: https://reviews.llvm.org/D119173
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
Back in https://reviews.llvm.org/D109459, we stopped using the C++03
emulation for std::nullptr_t by default, which was an ABI break. We
still left a knob for users to turn it back on if they were broken by
the change, with a note that we would remove that knob after one release.
The time has now come to remove the knob and clean up the std::nullptr_t
emulation.
Differential Revision: https://reviews.llvm.org/D114786
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.
David Spickett