At the moment the ftm macro for __cpp_lib_to_chars will have the
following values:
standard_ftms: {
"c++17": "201611L",
"c++20": "201611L",
"c++23": "201611L",
"c++26": "201611L",
}
implemented_ftms: {
"c++17": None,
}
This is an issue with the test whether the FTM is implemented it does:
self.implemented_ftms[ftm][std] == self.standard_ftms[ftm][std]
This will fail in C++20 since implemented_ftms[ftm] does not have the
key c++20. This adds a new helper function and removes the None entries
when a FTM is not implemented.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
The Apple runners automatically pick up newer XCode versions breaking
the CI. This disables the test to get the CI green which allows us to
investigate the issue properly later on.
# Overview
As a disclaimer, this is my first PR to LLVM and while I've tried to
ensure I've followed the LLVM and libc++ contributing guidelines,
there's probably a good chance I missed something. If I have, just let
me know and I'll try to correct it as soon as I can.
This PR implements `std::ranges::iota` and
`std::ranges::out_value_result` outlined in
[P2440r1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html).
As outlined in the paper above, I've:
- Implemented `out_value_result` and added to `<algorithm>`
- Added `out_value_result`, `iota_result`, and two overloads of `iota`
to `std::ranges` in `<numeric>`
- Updated the version macro `__cpp_lib_ranges_iota` in `<version>`
I've also added tests for `ranges::iota` and `ranges::out_value_result`.
Lastly, I added those structs to the appropriate module files.
Partially implements #105184
EDIT: Forgot to mention in the original post, thanks to @hawkinsw for
taking a look at a preliminary version of this PR!
# TODOs
- [x] Updating the range [status
doc](https://github.com/jamesETsmith/llvm-project/blob/main/libcxx/docs/Status/RangesMajorFeatures.csv)
- [x] Ensure all comments from https://reviews.llvm.org/D121436 are
addressed here
- [X] EDIT (I'll do this in a separate PR). ~~I'm open to implementing
the rest of P2440r1 (`ranges::shift_left` and `ranges::shift_right`) if
that's ok, I just wanted to get feedback on `ranges::iota` first~~
- [x] I've been having trouble building the modules locally and want to
make sure that's working properly
Closes: #134060
clang-19 changed how Arm triples were normalised and so while we
supported 18 and 19, we could not hard code the path here.
Now that Linaro's bots are running clang-19, and libcxx is going to drop
clang-18 support (https://github.com/llvm/llvm-project/pull/130142) I
have simplified it by hard coding the path again.
I also looked into why this exists in the first place. It was added in
https://reviews.llvm.org/D154246 but not questioned at the time.
It is due to the way we build compiler-rt, which is due to the final
layout we need in the install:
1. The builtins library must be called libclang_rt.builtins.a for clang
to find it. There must not be an architecture name in the filename.
2. That builtins library must be directly in lib/, next to picolib's
installed files.
To achieve number 1 we must set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
However, that causes the file to be installed in a per-target dir which
breaks number 2. So to fix that, we move the builtins library up one
level into lib/.
The alternative is to turn off per-target dirs, which results in a
builtin file with an arch in the name, then rename and move that file
(since it gets installed into lib/generic/).
So in the end, it's the same amount of hacks. I think it's best to keep
the one that uses LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON, as this is the
recommended way to built these days.
This isn't the whole team, but enough that one of us will see it and
make sure the right person sees it.
Noted explicitly that Picolibc is also our responsiblity as it's not
always clear that that is tested on Arm.
As discussed during the last monthly meeting we want to be able to test
the GCC development version in our CI, but we don't want to commit to
support this compiler version.
This adds the image to the CI Docker image. At the moment GCC-15 will
not pass the CI. Having it in the Docker image makes it possible to
validate fixes.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Co-authored-by: Hristo Hristov <hghristov.rmm@gmail.com>
In recent versions of Clang, using -std=c++20 (and later) implies LSV
when compiling with modules. This change resulted in making our LSV job
redundant with the regular modules job, which uses the latest Standard.
This patch increases the coverage of our CI without increasing its cost
by pinning the LSV job to use C++17, which normally doesn't use LSV. A
related question is whether we should add coverage for non-LSV builds
using Clang modules.
The patch that added the new locale Lit features was created before we
switched to a 0-1 macro for _LIBCPP_HAS_WIDE_CHARACTERS, leading to that
patch referring to the obsolete _LIBCPP_HAS_NO_WIDE_CHARACTERS macro
that is never defined nowadays.
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.
