P2321R2 has been implemented in various PRs. Based on the discussion
in #105169, the last bit in iterator.concept.winc doesn't require
any changes, so we can actually mark this as done.
Fixes#105169
The existence of <float.h> in libc++ leads to difficulties with modules,
especially when it comes to supporting the various __need macros
supported by the Clang builtin headers.
Fortunately, libc++'s <float.h> only defines FLT_EVAL_METHOD and
DECIMAL_DIG, which are already defined by the Clang builtin headers in
C++11 mode. Hence, removing the header entirely should have no impact,
apart from not defining FLT_EVAL_METHOD and DECIMAL_DIG in C++03 mode.
However, that is arguably something that libc++ shouldn't be doing: if
the underlying C library doesn't want to provide these definitions, then
libc++ shouldn't force it to.
We haven't yet decided what we want the `optional::iterator` type to be
in the end, so let's make it experimental for now so that we don't
commit to an ABI yet.
Originally some `[[nodiscard]]` tests were implemented in
`*/test/libcxx/diagnostics`. The Standard has a library `Diagnostics`
and this folder should be reserved for it by convention. Most newer
tests were added to their respective sub-folders. This patch moves
around the already implemented `[[nodiscard]]` tests to their respective
folders where they belong and standardizes the name to
`nodiscard.verify.cpp` wherever possible.
N.B. This refactors only tests, which were merged. The remaining
(in-progress) ones will be moved in a future patch to reduce merge
conflicts.
[P1789R3](https://isocpp.org/files/papers/P1789R3.pdf) was accepted for
C++26 through LWG motion 14 at the 2025 Kona meeting. This patch
implements it, along with tests and documentation changes.
Closes#167268
---------
Co-authored-by: Tsche <che@pydong.org>
This implements all of [P2404R3](https://wg21.link/p2404r3)'s concept
changes.
---------
Co-authored-by: A. Jiang <de34@live.cn>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Per [LWG554](https://cplusplus.github.io/LWG/issue554), the rationale is
that even if `true / false` traps, the values causing trap are the
converted `int` values produced by usual arithmetic conversion, but not
the original `bool` values.
This is also true for all other non-promoted integer types. As a result,
`std::numeric_limits<I>` should be `false` if `I` is a non non-promoted
integer type.
Fixes#166053.
Resolves#148131
- Unlock `std::optional<T&>` implementation
- Allow instantiations of `optional<T(&)(...)>` and `optional<T(&)[]>`
but disables `value_or()` and `optional::iterator` + all `iterator`
related functions
- Update documentation
- Update tests
This commit adds move constructor, move assignment and `swap`
to `exception_ptr`. Adding those operators allows us to avoid
unnecessary calls to `__cxa_{inc,dec}rement_refcount`.
Performance results (from libc++'s CI):
```
Benchmark Baseline Candidate Difference % Difference
------------------------------------ ---------- ----------- ------------ --------------
bm_exception_ptr_copy_assign_nonnull 9.77 9.94 0.18 1.79%
bm_exception_ptr_copy_assign_null 10.29 10.65 0.35 3.42%
bm_exception_ptr_copy_ctor_nonnull 7.02 7.01 -0.01 -0.13%
bm_exception_ptr_copy_ctor_null 10.54 10.60 0.06 0.56%
bm_exception_ptr_move_assign_nonnull 16.92 13.76 -3.16 -18.70%
bm_exception_ptr_move_assign_null 10.61 10.76 0.14 1.36%
bm_exception_ptr_move_ctor_nonnull 13.31 10.25 -3.06 -23.02%
bm_exception_ptr_move_ctor_null 10.28 7.30 -2.98 -28.95%
bm_exception_ptr_swap_nonnull 19.22 0.63 -18.59 -96.74%
bm_exception_ptr_swap_null 20.02 7.79 -12.23 -61.07%
```
As expected, the `bm_exception_ptr_copy_*` benchmarks are not influenced by
this change. `bm_exception_ptr_move_*` benefits between 18% and 30%. The
`bm_exception_ptr_swap_*` tests show the biggest improvements since multiple
calls to the copy constructor are replaced by a simple pointer swap.
While `bm_exception_ptr_move_assign_null` did not show a regression in the CI
measurements, local measurements showed a regression from 3.98 to 4.71, i.e. by
18%. This is due to the additional `__tmp` inside `operator=`. The destructor
of `__other` is a no-op after the move because `__other.__ptr` will be a
nullptr. However, the compiler does not realize this, since the destructor is
not inlined and is lacking a fast-path. As such, the swap-based implementation
leads to an additional destructor call. `bm_exception_ptr_move_assign_nonnull`
still benefits because the swap-based move constructor avoids unnecessary
__cxa_{in,de}crement_refcount calls. As soon as we inline the destructor, this
regression should disappear again.
Works towards #44892
<https://wg21.link/P2641R4>
Implements the C++26 function in `<type_traits>` [meta.const.eval] (and
the corresponding feature test macro `__cpp_lib_is_within_lifetime`)
```c++
template<class T>
consteval bool is_within_lifetime(const T*) noexcept;
```
This is done with the `__builtin_is_within_lifetime` builtin added to
Clang 20 by #91895 / 2a07509c8d3c8b5b2c88e4f73dde0071bf506870. This is
not (currently) available with GCC.
This implementation has provisions for LWG4138
<https://cplusplus.github.io/LWG/issue4138> where it is ill-formed to
instantiate `is_within_lifetime<T>` with a function type `T`.
Closes#105381
Co-authored-by: Mital Ashok <mital@mitalashok.co.uk>
`__alignas_is_defined` and `__alignof_is_defined` are a C++11 feature
which we only recently added. I don't think it will break anybody if we
don't provide these macros in C++03, so this simply disable the test
instead.
Apple dropped support for some older platforms, so we can also remove
the annotations for them.
See https://developer.apple.com/support/xcode/ for the supported
versions.
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
