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
This also removes some tests which were redundant, wrong, or never run.
Specifically,
- `libcxx/utilities/meta/stress_tests/*` were never run and are of
questionable usefulness
- `libcxx/utilities/template.bitset/includes.pass.cpp` is completely
redundant and partially incorrect
Also notably,
`libcxx/language.support/support.c.headers/support.c.headers.other/math.lerp.verify.cpp`
has been refactored to only test the standard mandate.
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)
Both Clang and GCC diagnose invalid calls to `__builtin_launder`, which
causes duplicate diagnostics when using `std::launder` in an invalid
way. While the diagnostic message for the builtin isn't perferct, it's
definitely good enough to understand the problem and adding our own
diagnostic doesn't really make things any clearer. Because of that, this
patch simply removes the `static_assert`s and lets the compiler handle
diagnosing incorrect arguments instead. This not only simplifies our
implementation, but also improves compile times a bit, since we avoid
instantiating some type traits.
Libc++'s policy is to support only the latest released Xcode, which is
Xcode 16.x. We did update our CI jobs to Xcode 16.x, but we forgot to
update the documentation, which still mentioned Xcode 15. This patch
updates the documentation and cleans up outdated mentions of
apple-clang-15 in the test suite.
Clang treats throwing/catching ObjC types differently from C++ types,
and omitting the `throw` in `std::make_exception_ptr` breaks ObjC
invariants about how types are thrown/caught.
Fixes#135089
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
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.
The underlying bug in vcruntime [1] has been fixed in the latest version
of MSVC (released two weeks ago); this will cause the test which is
currently marked XFAIL to start erroring, when it starts passing
unexpectedly.
This version of MSVC may soon start appearing in the Github Actions
runner images used for our CI.
We could try to detect the state of this bug, but in practice, such
detection code would essentially be a copy of this whole test.
Therefore, just mark this test UNSUPPORTED for the MSVC mode builds. If
we at some point require new enough MSVC libraries, we could remove the
marking entirely.
[1]
https://developercommunity.visualstudio.com/t/vcruntime-nothrow-array-operator-new-fal/10373274
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.
Requirements on character-like types are updated unconditionally,
because `basic_string` does requires the default-constructibility. It
might be possible to make `basic_string_view` support classes with
non-public trivial default constructor, but this doesn't seem sensible.
libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated
features.
# 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
This relies on Clang's no_specializations attribute which is not
supported by GCC.
Implements:
- LWG2129: User specializations of std::initializer_list
Fixes: #126270
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`.
These functions weren't added until API 26 (Android 8.0), but libc++ is
supported for API 21 and up.
These APIs are undeclared as of r.android.com/3216959.
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 disentangles the code which previously had a mix of many #ifdefs, a
non-versioned namespace and a versioned namespace. It also makes it
clearer which parts of <new> are implemented on Windows by including <new.h>.
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.
The Android clang-r536225 compiler identifies as Clang 19, but it is
based on commit fc57f88f007497a4ead0ec8607ac66e1847b02d6, which predates
the official LLVM 19.0.0 release.
Some tests need fixes:
* The sized delete tests fail because clang-r536225 leaves sized
deallocation off by default.
* std::array<T[0]> is true when this Android Clang version is used with
a trunk libc++, but we expect it to be false in the test. In practice,
Clang and libc++ usually come from the same commit on Android.
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>
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
Only the [cmp.alg] part (for `comparison_meow_fallback` CPOs) in the
paper required changes. Other parts merely fixed preconditions of some
standard library functions.
I strongly feel that P2167R3 should be a DR despite that it is not a DR
officially: CPOs -> C++20; remain parts -> C++98/11 (except that
_`boolean-testable`_ should be transformed into the original
_BooleanTestable_ requirements in the old resolution of LWG2114).
Note that P2167R3 damaged the resolution of LWG3465: the type of `F < E`
was left underconstrained. I've tried to submit an LWG issue for this,
which is now LWG4157.
Drive-by change:
- enable some test coverages in `compare_strong_order_fallback.pass.cpp`
when `TEST_LONG_DOUBLE_IS_DOUBLE`, following up #106742Closes#105241.
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
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.
