Resolves#105430
- Implement all required pieces of P3168R2
- Leverage existing `wrap_iter` and `bounded_iter` classes to implement
the `optional` regular and hardened iterator type, respectively
- Update documentation to match
And constrain the new `operator==` since C++26.
This patch implements parts of P2165R4, P2944R3, and a possibly improved
resolution of LWG3882. Currently, libstdc++ and MSVC STL constrain the
new overloads in the same way.
Also set feature-test macro `__cpp_lib_constrained_equality` and add
related release note, as P2944R3 will completed with this patch.
Fixes#136765Fixes#136770Fixes#105424
Fixes a small annoyance where generated files have a format which does
not agree with the one checked during `code-formatter` in CI.
For example `libcxx-generate-files` updates (among possibly others) the
`*.version.compile.pass.cpp` files. Previously these files contained an
extra newline which would fail the code format check. If you update that
file manually to remove just that extra trailing newline, then
`check-generated-output` will fail due to the file's contents differing
from what's expected.
Contains a number of changes: one actual change to the py script, and
lots of resulting whitespace changes.
My process for this was:
* Update `generate_feature_test_macro_components`: just remove an extra
newline which causes the code-format step to fail
* Run `$NINJA libcxx-generate-files` to rebuild all these
`.version.pass.cpp`'s
* Watch this PR's CI run to ensure things pass (i.e. this didn't break
things worse)
Fixes#105260
This patch applies the change as a DR to C++20. The rationale is that
the paper is more like a bug fix. It does not introduce new features, it
simply changes an existing behaviour (as a bug fix). MSVC STL DRed this
paper to C++20 as well.
Adjusting the existing script to match the new output makes it easy to
review the new script works correctly.
This adjusts the tests to match the changes in the new tests, Notably
- removes the synopsis uses 2 spaces indent in `# if`
It does not implement the conditional include part. This would be quite
some effort and these diffs are easy to review manually.
Note there are no tests for the changes; the existing script will be
phased out when the next generators are complete.
# 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
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 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`.
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
We waited before supporting std::jthread fully because we wanted to
investigate other implementation strategies (in particular one involving
std::mutex). Since then, we did some benchmarking and decided that we
wouldn't be moving forward with std::mutex. Hence, there is no real
reason to punt on making std::jthread & friends non-experimental.
This patch implements https://wg21.link/P2747R2.
The library changes affect direct `operator new` and `operator new[]`
calls even when the core language changes are absent.
The changes are not available for MS ABI because the `operator new` and
`operator new[]` are from VCRuntime's `<vcruntime_new.h>`. A feature
request was submitted for that [1].
As a drive-by change, the patch reformatted the whole `new.pass.cpp` and
`new_array.pass.cpp` tests.
Closes#105427
[1]: https://developercommunity.visualstudio.com/t/constexpr-for-placement-operator-newope/10730304.
This patch implements https://wg21.link/p2609r3.
The test code was originally authored by JMazurkiewicz.
Notes:
- P2609R3 is not officially a Defect Report, but MSVC STL
implements it in C++20 mode.
Moreover, P2609R3 and P2997R1 touch exactly the same set of
concepts, and MSVC STL and libc++ have already treated P2997R1
as a DR.
- This patch also adjusted feature-test macros.
+ In C++20 mode, the value of __cpp_lib_ranges should be `202110L` because
- `202202L` covers `range_adaptor_closure` (P2387R3), and
- `202207L` covers move-only types in range adaptors (P2494R2).
And all of these changes are only available since C++23 mode.
+ In C++23 mode, the value should be `202406L` because
- `202211L` covers removing poison overloads (P2602R2),
- `202302L` covers relaxing projected value types (P2609R3), and
- `202406L` covers removing requirements on `iter_common_reference_t` (P2997R1).
And all of these changes are already or being implemented.
Fixes#105253.
Co-authored-by: Jakub Mazurkiewicz <mazkuba3@gmail.com>
This trait is implemented in C++26 conditionally on the compiler
supporting the __builtin_is_virtual_base_of intrinsic. I believe only
tip-of-trunk Clang currently implements that builtin.
Closes#105432
Implements [P1223R5][] completely.
Includes an implementation of `find_last`, `find_last_if`, and
`find_last_if_not`.
[P1223R5]: https://wg21.link/p1223r5
This patch implements P2389R2, which was adopted at the St. Louis meeting.
It builds upon previous enhancements from P2299R3, which introduced deduction
guides and the `dextents` alias template.
In order to define the format __cpp_lib_format to its initial value
(201907) these papers need to be completed:
- P0645R10 Text Formatting
- P1652R1 Printf corner cases in std::format
- 1361R2 Integration of chrono with text formatting The first two have
been implemented for a while the latter is almost done.
The next value (202106) requires:
- P2216R3 std::format improvements which has been implemented
The next value (202110) requires:
- P2418R2 Add support for std::generator-like types to std::format
- P2372R3 Fixing locale handling in chrono formatters The first one has
been implemented for a while the latter is almost done. The latter paper
is a DR against 1361R2 and both are implemented at the same time.
We've had user feedback that the missing of the __cpp_lib_format makes
their lives harder (https://github.com/llvm/llvm-project/issues/77773).
The missing papers 1361R2 and P2372R3 are very close to completion and
might completed before LLVM-19, but it will be a close call. This has
been discussed in the monthly libc++ meeting and we decided to set the
__cpp_lib_format so it will be set in LLVM-19.
Based on the discussion and the implementation status the
__cpp_lib_format is set to 202110.
Fixes#77773
The feature has been implemented in LLVM 18 as an experimental feature.
This marks the paper as complete and sets the feature-test macro.
Implements
- P2465R3 Standard Library Modules std and std.compat
Fixes: https://github.com/llvm/llvm-project/issues/89579
The paper
P0768R1 Library Support for the Spaceship (Comparison) Operator
did not add a feature-test macro. This omission has been corrected in
P1353R0 Missing Feature Test Macros
This enables the FTM for P0768R1
Fixes: https://github.com/llvm/llvm-project/issues/73953
---------
Co-authored-by: S. B. Tam <cpplearner@outlook.com>
[P2845R8](https://wg21.link/P2845R8) "Formatting of
`std::filesystem::path`" and [P2587R3](https://wg21.link/P2587R3)
"`to_string` or not `to_string`" are C++26 features, so they should be
marked accordingly in `generate_feature_test_macro_components.py`.
I verified that without my changes, running the script produced no
edits. Then with my changes, I ran the script to regenerate all files,
with no other manual edits.
Found while running libc++'s tests with MSVC's STL, which noticed this
because it's currently a C++23-only implementation.
Note that @H-G-Hristov has a draft implementation of P2587R3: #78100
We noticed that some feature-test macros were not conditional on
configuration flags like _LIBCPP_HAS_NO_FILESYSTEM. As a result, code
attempting to use FTMs would not work as intended.
This patch adds conditionals for a few feature-test macros, but more
issues may exist.
rdar://122020466
