This tests seems problematic on different platforms. There is still a
test that ensures coverage, but in an automatic fashion. This test needs
to be investigated.
When we initially implemented the C++20 synchronization library, we
reluctantly accepted for the implementation to be backported to C++03
upon request from the person who provided the patch. This was when we
were only starting to have experience with the issues this can create,
so we flinched. Nowadays, we have a much stricter stance about not
backporting features to previous standards.
We have recently started fixing several bugs (and near bugs) in our
implementation of the synchronization library. A recurring theme during
these reviews has been how difficult to understand the current code is,
and upon inspection it becomes clear that being able to use a few recent
C++ features (in particular lambdas) would help a great deal. The code
would still be pretty intricate, but it would be a lot easier to reason
about the flow of callbacks through things like
__thread_poll_with_backoff.
As a result, this patch deprecates support for the synchronization
library before C++20. In the next release, we can remove that support
entirely.
The work-around in 26852565a5f609e6b466f43c2f690ce3047d04c7 didn't fix
the CI. Since the entire local database is compared with the libc++
implementation in a separate this this change does not remove coverage.
LWG3869 Deprecate std::errc constants related to UNIX STREAMS
deprecates the POSIX macros ENODATA, ENOSR, ENOSTR, and ETIME. These
were deprecated in libc++ in
https://github.com/llvm/llvm-project/pull/80542. Based on the post
commit feedback the macro are no longer deprecated. Instead libc++
leaves the deprecation to the provider of errno.h.
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
## Abstract
This pull request implements [P3029R1](https://wg21.link/P3029R1). The
paper discusses the current behavior of `mdspan`'s most common
pointer-indices CTAD, where the `Extents` template parameter is deduced
as `dextents` (dynamic extents), even when passing compile-time constant
values. The author believes this behavior is suboptimal, as it doesn't
take advantage of the compile-time information. The proposed change
suggests deducing static extents if `integral_constant`-like constants
are passed, resulting in more intuitive syntax and less error-prone
code.
## Reference
- [P3029R1](https://wg21.link/P3029R1)
- [Draft C++ Standard: [span.syn]](https://eel.is/c++draft/span.syn)
- [Draft C++ Standard: [mdspan.syn]](https://eel.is/c++draft/mdspan.syn)
This pull request implements LWG3643: Missing constexpr in
std::counted_iterator. Specifically, one overload of
std::counted_operator::operator++ was not marked as constexpr,
despite being eligible for it after the introduction of try-block
support in constexpr functions in C++20.
Adds the sys_info class and time_zone::get_info(). The code still has a
few quirks and has not been optimized for performance yet.
The returned sys_info is compared against the output of the zdump tool
in the test giving confidence the implementation is correct.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Implements:
- LWGXXXX The sys_info range should be affected by save
This was actually already implemented in the initial version of
std::expected, but this patch adds test coverage and makes it more
explicit that we intend to make these functions noexcept.
It adds the missing member functions of the tzdb class and adds the free
functions that use these member functions.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Spotted this minor mistake in the tests as I was looking into testing
more thoroughly `atomic_ref`.
The two argument overloads are tested just above. The names of the
lambda clearly indicates that the intent was to test the one argument
overload.
This implements the loading of the leap-seconds.list file and store its
contents in the tzdb struct.
This adds the required `leap_seconds` member.
The class leap_seconds is fully implemented including its non-member
functions.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
- P1614 The Mothership has Landed
Implements:
- P1981 Rename leap to leap_second
- LWG3359 <chrono> leap second support should allow for negative leap
seconds
- LWG3383 §[time.zone.leap.nonmembers] sys_seconds should be replaced
with seconds
One or two of the tests need slight tweaks to make them pass when
building with musl.
This patch is a re-application of b61fb18 which was reverted in 0847c90
because it broke the build.
rdar://118885724
Co-authored-by: Alastair Houghton <ahoughton@apple.com>
Both `std::distance` or `ranges::distance` are inefficient for
non-sized ranges. Also, calculating the range using `int` type is
seriously problematic.
This patch avoids using `distance` and calculation of the length of
non-sized ranges.
Fixes#86833.
Currently, the bounds check in `std::ranges::advance(it, n, s)` is done
_before_ `n` is checked. This results in one extra, unneeded bounds
check.
Thus, `std::ranges::advance(it, 1, s)` currently is _not_ simply
equivalent to:
```c++
if (it != s) {
++it;
}
```
This difference in behavior matters when the check involves some
"expensive" logic. For example, the `==` operator of
`std::istreambuf_iterator` may actually have to read the underlying
`streambuf`.
Swapping around the checks in the `while` results in the expected
behavior.
This moves the definition of a `pair` constructor for `<tuple>` to
`<__utility/pair.h>` and uses the forward declaration of `pair` in
`<tuple>` instead of including the definition.
The exposition-only type trait `pair-like` includes `ranges::subrange`,
but in every single case excludes `ranges::subrange` from the list. This
patch introduces two new traits `__tuple_like_no_subrange` and
`__pair_like_no_subrange`, which exclude `ranges::subrange` from the
possible matches. `__pair_like` is no longer required, and thus removed.
`__tuple_like` is implemented as `__tuple_like_no_subrange` or a
`ranges::subrange` specialization.
On z/OS int128 is disabled causing one of the cases in
`saturate_cast.pass.cpp` to fail. The failure is only in 64-bit mode.
In this case `the std::numeric_limits<long long int>::max()` is within
`std::numeric_limits<unsigned long int>::min()`
and `std::numeric_limits<unsigned long int>::max()` therefore,
saturate_cast<unsigned long int>( sBigMax) == LONG_MAX and not ULONG_MAX
as original test.
In 32-bit, `saturate_cast<unsigned long int>( sBigMax) == ULONG_MAX`
like on other platforms where int128 is enabled.
This PR is required to pass this test case on z/OS and possibly on other
platforms where int128 is not supported/enabled.
---------
Co-authored-by: Sean Perry <perry@ca.ibm.com>
Implement [LWG3528](https://wg21.link/LWG3528).
Based on LWG3528(https://wg21.link/LWG3528) and
http://eel.is/c++draft/description#structure.requirements-9, the
standard allows to impose requirements, we constraint
`std::make_from_tuple` to make `std::make_from_tuple` SFINAE friendly
and also avoid worse diagnostic messages. We still keep the constraints
of `std::__make_from_tuple_impl` so that `std::__make_from_tuple_impl`
will have the same advantages when used alone.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Fixes#75975.
Remove `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` for the LLVM 19
release, it was previously marked as deprecated in LLVM 18.
I believe that
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` was only
used by Google in conjunction with
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`.
Removing both macros together should not cause any issues in practice,
even though we did not announce the removal of
`_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` before.
## Abstract
This pull request implements LWG3715: `view_interface::empty` is
overconstrained. Here is an example similar to those described in the
report, which compiles with `-stdlib=libstdc++` but failed to compile
with `-stdlib=libc++`:
```cpp
// https://godbolt.org/z/EWEoTzah3
std::istringstream input("1 2 3 4 5");
auto i = std::views::istream<int>(input);
auto r = std::views::counted(i.begin(), 4) | std::views::take(2);
assert(!r.empty());
```
## Reference
- [Draft C++ Standard:
[view.interface.general]](https://eel.is/c++draft/view.interface.general)
- [LWG3715](https://wg21.link/LWG3715)
On Windows you can not create symlinks without elevated privileges
unless you have Windows developer mode enabled. There's ~67 libcxx tests
that run into failures on windows if your environment is not set up
correctly (Go to windows settings and enable "developer mode").
This change:
- Adds a feature check for whether the host can create symlinks. (see
libcxx/utils/libcxx/test/features.py)
- Mark the feature as required for the 67 tests that hit failures on
windows due to this. This will allow lit to correctly mark these tests
as unsupported instead of unexpectedly failed (this is helpful since
then you know you didn't break something with your change, it's just
that it's not supported with your environment).
When calling setbuf(nullptr, 0) before performing file operations it
should set the file to unbuffered mode. Currently the code avoids
buffering internally, but the underlying stream still can buffer.
This is addressed by disabling the buffering of the underlying stream.
Fixes: https://github.com/llvm/llvm-project/issues/60509
