## Abstract
This pull request implements LWG3672: `common_iterator::operator->()`
should return by value. The current implementation specifies that this
function should return the underlying pointer by reference (`T*
const&`), but it would be more intuitive to return it by value (`T*`).
## Reference
- [Draft C++ Standard:
[common.iter.access]](https://eel.is/c++draft/common.iter.access)
- [LWG3672](https://cplusplus.github.io/LWG/issue3672)
I strongly suspect nobody ever used that macro since it wasn't very well
known. Furthermore, it only affects a handful of diagnostics and I think
it makes sense to either provide them unconditionally, or to not
provided them at all.
Implement
- LWG4053 Unary call to `std::views::repeat` does not decay the argument
- LWG4054 Repeating a `repeat_view` should repeat the view
Signed-off-by: yronglin <yronglin777@gmail.com>
This pull request implements LWG3984: ranges::to's recursion branch
may be ill-formed.
In the current implementation, ranges::to's recursion branch pipes the
range into a `views::transform(/* lambda */)`, which is a __range_adaptor_closure
object. In libc++, the pipe operator of __range_adaptor_closure requires a
viewable_range, so the following code won't compile, as the type of lvalue
`r` doesn't model viewable_range:
#include <ranges>
#include <vector>
#include <list>
int main() {
std::vector<std::vector<int>> v;
auto r = std::views::all(std::move(v));
auto l = std::ranges::to<std::list<std::list<int>>>(r);
}
Co-authored-by: A. Jiang <de34@live.cn>
The change increments the size of the lookup table considerably. The
table has an "upper boundary" check. The removal of the code units with
the property Grapheme_Extend=Yes removes the range E0100..E01EF. This
breaks the trailing large continuous section in two parts. This will be
improved in a followup patch.
Implements:
- P2713R1 Escaping improvements in std::format
- LWG3965 Incorrect example in [format.string.escaped] p3 for formatting
of combining characters
```
---------------------------------------------------------
Benchmark Before After
---------------------------------------------------------
BM_ascii_escaped<char> 95696 ns 110704 ns
BM_unicode_escaped<char> 89311 ns 101371 ns
BM_cyrillic_escaped<char> 58633 ns 63329 ns
BM_japanese_escaped<char> 44500 ns 41223 ns
BM_emoji_escaped<char> 99156 ns 111022 ns
BM_ascii_escaped<wchar_t> 92245 ns 112441 ns
BM_unicode_escaped<wchar_t> 80970 ns 102776 ns
BM_cyrillic_escaped<wchar_t> 51253 ns 58977 ns
BM_japanese_escaped<wchar_t> 37252 ns 36885 ns
BM_emoji_escaped<wchar_t> 96226 ns 115885 ns
```
This patch implements LWG4023 by adding explicit assertions for the
added preconditions and also fixes a few tests that were violating these
preconditions.
CMake has landed experimental support for using the Standard modules.
This will be part of the CMake 3.30 release. This updates the build
instructions to use modules with CMake.
The changes have been tested locally.
---------
Co-authored-by: Will Hawkins <whh8b@obs.cr>
This patch finalizes the std::ranges::range_adaptor_closure
class template from https://wg21.link/P2387R3.
// [range.adaptor.object], range adaptor objects
template<class D>
requires is_class_v<D> && same_as<D, remove_cv_t<D>>
class range_adaptor_closure { };
The current implementation of __range_adaptor_closure was introduced
in ee44dd8062a26541808fc0d3fd5c6703e19f6016 and has served as the
foundation for the range adaptors in libc++ for a while. This patch
keeps its implementation, with the exception of the following changes:
- __range_adaptor_closure now includes the missing constraints
`is_class_v<D> && same_as<D, remove_cv_t<D>>` to restrict the
type of class that can inherit from it. (https://eel.is/c++draft/ranges.syn)
- The operator| of __range_adaptor_closure no longer requires its
first argument to model viewable_range. (https://eel.is/c++draft/range.adaptor.object#1)
- The _RangeAdaptorClosure concept is refined to exclude cases where
T models range or where T has base classes of type range_adaptor_closure<U>
for another type U. (https://eel.is/c++draft/range.adaptor.object#2)
This adds the local_info type and its formatting options.
The usage of the local_info object will be done in separate patches.
Implements parts of:
- P0355 Extending to Calendars and Time Zones
- P1361 Integration of chrono with text formatting
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.
## 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.
Since we have released Clang 16 is no longer actively supported. However
the FreeBSD runner is still using this, so some tests still guard
against Clang 16.
Justifications:
- LWG3950: Done in #66206
- LWG3975: Wording changes only
- LWG4011: Wording changes only
- LWG4030: Wording changes only
- LWG4043: Wording changes only
- LWG3036 and P2875R4: We implemented neither, but the latter reverts
the former, so now we implement both without doing anything!
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
The section discusses the reasons for the libraries inception more than
a decade ago. Now it discusses the progess libc++ has made, and the many
impressive acomplishments our contributors have brought it.
The initial section remains below.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
We've been applying ``[[nodiscard]]`` more liberally recently, but we
don't have any documented guidance on when it's correct to add it. This
patch adds that guidance. Follow-up patches will gradually apply it to
the code base.
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)
This reverts commit 4109b18ee5de1346c2b89a5c89b86bae5c8631d3.
It looks like the automatic detection has false positives. This broke
the following build https://github.com/llvm/llvm-project/pull/85262
