- add zip_view and views::zip for C++23
- added unit tests
- implemented section 5.6 (zip) in P2321R2
I used clang-format to format the files but they look nothing like the rest of the code base. Manually indenting each line to match the styles sounds like an impossible task. Is there any clang-format file which can format it reasonable similar to the rest of the code base so that I can manually format the rest lines that look weird?
Reviewed By: ldionne, #libc, philnik, var-const
Spies: Mordante, philnik, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D122806
D123182 fixes a bug in Clang's overload resolution. After it landed it
was discovered `basic_format_arg`'s constructors contains this bug. This
fixes the bug in libc++, unblocking D123182.
The code has been tested in combination with D123182.
Reviewed By: royjacobson, #libc
Differential Revision: https://reviews.llvm.org/D124103
`vector<bool>::const_reference` and `vector<bool>::const_iterator::reference` should be the same type.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123851
This makes the code a bit simpler and (I think) removes the undefined behaviour from the normal string layout.
Reviewed By: ldionne, Mordante, #libc
Spies: labath, dblaikie, JDevlieghere, krytarowski, jgorbe, jingham, saugustine, arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123580
- added views::join adaptor object
- added test for the adaptor object
- fixed some join_view's tests. e.g iter_swap test
- added some negative tests for join_view to test that operations do not exist when constraints aren't met
- added tests that locks down issues that were already addressed in previous change
- LWG3500 `join_view::iterator::operator->()` is bogus
- LWG3313 `join_view::iterator::operator--` is incorrectly constrained
- LWG3517 `join_view::iterator`'s `iter_swap` is underconstrained
- P2328R1 join_view should join all views of ranges
- fixed some issues in join_view and added tests
- LWG3535 `join_view::iterator::iterator_category` and `::iterator_concept` lie
- LWG3474 Nesting ``join_views`` is broken because of CTAD
- added tests for an LWG issue that isn't resolved in the standard yet, but the previous code has workaround.
- LWG3569 Inner iterator not default_initializable
Reviewed By: #libc, var-const
Spies: var-const, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123466
Note that this class was called just `split_view` in the original One
Ranges Proposal and was renamed to `lazy_split_view` by
[P2210](https://wg21.link/p2210).
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D107500
When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).
However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.
This should solve some of the issues encountered in D65667.
Differential Revision: https://reviews.llvm.org/D123519
The Android platform does not have ndk-version.h, but it will always
have up-to-date libc headers, so it does not need any compatibility
code intended for past versions of NDK_MAJOR. If ndk-version.h is missing,
assume NDK_MAJOR is (conceptually) infinite
Bug: https://buganizer.corp.google.com/issues/222341313
Test: None
This supersedes and incoroporates content from both D108906 and D54966,
and also some original content.
Co-Authored-by: Marshall Clow <mclow.lists@gmail.com>
Co-Authored-by: Gonzalo Brito Gadeschi
Differential Revision: https://reviews.llvm.org/D118938
Use a specialized "buffer" to count the number of insertions instead of
using a `string` as storage type.
Depends on D110497.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110498
Instead of writing every character directly into the container by using
a `back_insert_iterator` the data is buffered in an `array`. This buffer
is then inserted to the container by calling its `insert` member function.
Since there's no guarantee every container's `insert` behaves properly
containers need to opt-in to this behaviour. The appropriate standard
containers opt-in to this behaviour.
This change improves the performance of the format functions that use a
`back_insert_iterator`.
Depends on D110495
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110497
This is to simplify the changes made in D122780. This diff was generated using the command:
```
clang-format include/__algorithm/sort.h -i
```
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D122858
Adds a `__get_container` member as suggested by @Quuxplusone in D110497.
Includes s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/.
Reviewed By: Quuxplusone, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110573
`__is_callable` is required to ensure that the classic algorithms are only called with functions or functors. I also begin to granularize `<type_traits>`.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D123114
We are introducing branchless variants for sort3, sort4 and sort5.
These sorting functions have been generated using Reinforcement
Learning and aim to replace __sort3, __sort4 and __sort5 variants
for integral types.
The libc++ benchmarks were run on isolated machines for Skylake, ARM and
AMD architectures and achieve statistically significant improvement in
sorting random integers on test cases from sort1 to sort262144 for
uint32 and uint64.
A full performance overview for Intel Skylake, AMD and Arm can be
found here: https://bit.ly/3AtesYf
Reviewed By: ldionne, #libc, philnik
Spies: daniel.mankowitz, mgrang, Quuxplusone, andreamichi, philnik, libcxx-commits, nilayvaish, kristof.beyls
Differential Revision: https://reviews.llvm.org/D118029
Introduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERT
not call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.
Calling __builtin_assume was introduced in D122397.
__builtin_assume is generally supposed to improve optimizations, but can
cause regressions when LLVM has trouble handling the calls to
`llvm.assume()` (see comments in D122397).
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D123175
There are `constexpr` versions for the different `__invoke` functions, which seem to be identical other than begin `constexpr` since C++11 instead of being `constexpr` since C++20.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123003
The is a followup of D116965 to split the calendar header. This is a
preparation to add the formatters for the chrono header.
The code is only moved no other changes have been made.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D122995
This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.
Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D62641
[libc++] add global variable template std::views::empty
Note it is neither a range adaptor, nor a CPO. It is simplify a global variable template.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D122996
Note of the functions was marked as _LIBCPP_HIDE_FROM_ABI.
Did some minor formatting fixes to keep consistency. To keep it easy to
review not all odd formatting has been fixed.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122834
It seems to have been added back in 761e42fa3dd72 for Clang to use it,
however it seems to have never been used for that purpose, so it is
probably fine to remove it.
Differential Revision: https://reviews.llvm.org/D122330
This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
Since we expect the condition to be true most of the time, we might
as well tell the compiler. And when assertions are disabled, we
might as well tell the compiler that it's allowed to assume that
the condition holds.
Differential Revision: https://reviews.llvm.org/D122397
