There are 2 problems today that this PR resolves:
libcxx tests assume the thousands separator for fr_FR locale is x00A0 on
Windows. This currently fails when run on newer versions of Windows (it
seems to have been updated to the new correct value of 0x202F around
windows 11. The exact windows version where it changed doesn't seem to
be documented anywhere). Depending the OS version, you need different
values.
There are several ifdefs to determine the environment/platform-specific
locale conversion values and it leads to maintenance as things change
over time.
This PR includes the following changes:
- Provide the environment's locale conversion values through a
substitution. The test can opt in by placing the substitution value in a
define flag.
- Remove the platform ifdefs (the swapping of values between Windows,
Linux, Apple, AIX).
This is accomplished through a lit feature action that fetches the
environment's locale conversions (lconv) for members like
'thousands_sep' that we need to provide. This should ensure that we
don't lose the effectiveness of the test itself.
In addition, as a result of the above, this PR:
- Fixes a handful of locale tests which unexpectedly fail on newer
Windows versions.
- Resolves 3 XFAIL FIX-MEs.
Originally submitted in https://github.com/llvm/llvm-project/pull/86649.
Co-authored-by: Rodrigo Salazar <4rodrigosalazar@gmail.com>
Currently, there are a ton of `-- Installing:` and `-- Up-to-date:`
messages in the CI log, which just clutter the output. This disables
these messages to significantly shorten the CI logs, making them much
faster to load and easier to read.
This fixes some test failures when the libcxx tests are run against an
up-to-date picolibc on embedded Arm, because those tests depend on an
unsupported locale but the `hasAnyLocale` preliminary check wrongly
concluded that the locale _was_ supported.
`hasAnyLocale` passes a set of locale strings to a test program via the
command line, and checks if the libc under test reports that any of the
locales can be successfully set via setlocale(). In some invocations one
of the locale names contains a space, e.g. the Windows-style locale name
"English_United States.1252".
Unfortunately picolibc's crt0, when running under Arm semihosting,
fetches the single command string from the host and then splits it up at
spaces without implementing any kind of quoting. So it simply isn't
possible to get a space into an argv word. As a result, we end up
testing for the locale (in this example) "English_United". In up-to-date
versions of picolibc, this is actually accepted, since it contains no
objectionable character set specification (or indeed any at all). So the
lit check wrongly concludes that libc supports that locale, and enables
some locale tests, which fail.
This patch works around the issue entirely within `hasAnyLocale()`, by
abandoning the use of argv completely, and instead encoding the list of
locales to check as an array of strings inside the test program.
On older MacOS versions where `std::to_chars` for floating-point types
is not available the format library can't be used. Due to some issue
with the availability macro used to disable format on MacOS the issue
triggers regardless of the type being formatted.
The print library has the same issue.
Fixes: #125353
This changes the code to use dataclasses instead of dict entries. It
also adds type aliases to use in the typing information and updates the
typing information.
This PR addresses an undefined behavior that arises when using the
`std::fill` and `std::fill_n` algorithms, as well as their ranges
counterparts `ranges::fill` and `ranges::fill_n`, with `vector<bool, Alloc>`
that utilizes a custom-sized allocator with small integral types.
This is a continuation of what's been started in #89178.
As a drive-by, this also changes the PSTL macro to say `EXPERIMENTAL`
instead of `INCOMPLETE`.
GDB/MI requires unique names for each child, otherwise fails with
"Duplicate variable object name". Also wrapped containers printers
were flattened for cleaner visualization in IDEs and CLI.
Fixes#62340
This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public
header look like this:
```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```
In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.
This will allow using the $<LINK_LIBRARY> generator expression in some
of our configurations. We should separately pursue officially bumping
the minimum CMake version across all LLVM so we can use this feature
more widely.
When running a benchmark, also save the benchmark results in a JSON
file. That is cheap to do and useful to compare benchmark results
between different runs.
It makes more sense to start testing libc++ with the latest compiler and
only then to run the LLDB data formatter tests, since that provides more
signal than starting with the data formatter tests.
This patch refactors the tests around aligned allocation and sized
deallocation to avoid relying on passing the -fsized-deallocation or
-faligned-allocation flags by default. Since both of these features are
enabled by default in >= C++14 mode, it now makes sense to make that
assumption in the test suite.
A notable exception is MinGW and some older compilers, where sized
deallocation is still not enabled by default. We treat that as a "bug"
in the test suite and we work around it by explicitly adding
-fsized-deallocation, but only under those configurations.
This moves the configuration of the CMake features to turn off RTTI,
exceptions and friends to the beginning of the CMake file, where we
configure other optional parts of the library.
This fixes an important bug where we would disable the benchmarks
because these options were not defined yet, leading to the build
thinking they were defined to OFF.
This script does not depend on the generated headers since those are
already special-cased in header_information.py. Change the dependency
list to depend on header_information.py instead. While looking at this
code also simplify the assignment to libcxx_root inside this script.
This patch introduces a new kind of bounded iterator that knows the size
of its valid range at compile-time, as in std::array. This allows computing
the end of the range from the start of the range and the size, which requires
storing only the start of the range in the iterator instead of both the start
and the size (or start and end). The iterator wrapper is otherwise identical
in design to the existing __bounded_iter.
Since this requires changing the type of the iterators returned by
std::array, this new bounded iterator is controlled by an ABI flag.
As a drive-by, centralize the tests for std::array::operator[] and add
missing tests for OOB operator[] on non-empty arrays.
Fixes#70864
Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
Summary:
The GPU runs these tests using the files built from the `libc` project.
These will be placed in `include/<triple>` and `lib/<triple>`. We use
the `amdhsa-loader` and `nvptx-loader` tools, which are also provided by
`libc`. These launch a kernel called `_start` which calls `main` so we
can pretend like GPU programs are normal terminal applications.
We force serial exeuction here, because `llvm-lit` runs way too many
processes in parallel, which has a bad habit of making the GPU drivers
hang or run out of resources. This allows the compilation to be run in
parallel while the jobs themselves are serialized via a file lock.
In the future this can likely be refined to accept user specified
architectures, or better handle including the root directory by exposing
that instead of just `include/<triple>/c++/v1/`.
This currently fails ~1% of the tests on AMDGPU and ~3% of the tests on
NVPTX. This will hopefully be reduced further, and later patches can
XFAIL a lot of them once it's down to a reasonable number.
Future support will likely want to allow passing in a custom
architecture instead of simply relying on `-mcpu=native`.
This PR deprecates `<ccomplex>`, `<cstdbool>`, `<ctgmath>`, and
`<ciso646>` in C++17 and "removes" them in C++20 by special deprecation
warnings.
`<cstdalign>` is previously missing. This PR also tries to add them, and
then deprecates and "removes" `<cstdalign>`.
Papers:
- https://wg21.link/P0063R3
- https://wg21.link/P0619R4Closes#99985.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Around half of the tests are based on the tests Arthur O'Dwyer's
original implementation of std::flat_map, with modifications and
removals.
partially implement #105190
In C++20 mode, `__cpp_lib_optional` and `__cpp_lib_variant` should be
`202106L` due to DR P2231R1.
In C++26 mode, `__cpp_lib_variant` should be bumped to `202306L` due to
P2637R3.
- Clang 16/17 shouldn't get this bumping (as member `visit` requires
explicit object parameters), but it's very tricky to make the bumping
conditionally enabled. I _hope_ unconditionally bumping in C++26 will be
OK for LLVM 20 when the support for Clang 17 is dropped.
Related PRs:
- https://reviews.llvm.org/D102119
- #83335
- #76447
This reverts commit 68c04b0ae62d8431d72d8b47fc13008002ee4387.
This disables the IWYU mapping that caused the failure, since
the headers aren't reachable for now.
This is the first part of the "Freezing C++03 headers" proposal
explained in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc/77319/58.
This patch mechanically copies the headers as of the LLVM 19.1 release
into a subdirectory of libc++ so that we can start using these headers
when building in C++03 mode. We are going to be backporting important
changes to that copy of the headers until the LLVM 21 release. After the
LLVM 21 release, only critical bugfixes will be fixed in the C++03 copy
of the headers.
This patch only performs a copy of the headers -- these headers are
still unused by the rest of the codebase.
Since we don't generate a full dependency graph of headers, we can
greatly simplify the script that parses the result of --trace-includes.
At the same time, we also unify the mechanism for detecting whether a
header is a public/C compat/internal/etc header with the existing
mechanism in header_information.py.
As a drive-by this fixes the headers_in_modulemap.sh.py test which had
been disabled by mistake because it used its own way of determining
the list of libc++ headers. By consistently using header_information.py
to get that information, problems like this shouldn't happen anymore.
This should also unblock #110303, which was blocked because of
a brittle implementation of the transitive includes check which broke
when the repository was cloned at a path like /path/__something/more.
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
