Fixes#108624
This allows `flat_map::insert(Iter, Iter)` to directly forward to
underlying containers' `insert(Iter, Iter)`, instead of inserting one
element at a time, when input models "product iterator". atm,
`flat_map::iterator` and `zip_view::iterator` are "product iterator"s.
This gives about almost 10x speed up in my benchmark with -03 (for both
before and after)
```cpp
Benchmark Time CPU Time Old Time New CPU Old CPU New
-----------------------------------------------------------------------------------------------------------------------------------------------
flat_map::insert_product_iterator_flat_map/32 -0.5028 -0.5320 149 74 149 70
flat_map::insert_product_iterator_flat_map/1024 -0.8617 -0.8618 3113 430 3112 430
flat_map::insert_product_iterator_flat_map/8192 -0.8877 -0.8877 26682 2995 26679 2995
flat_map::insert_product_iterator_flat_map/65536 -0.8769 -0.8769 226235 27844 226221 27841
flat_map::insert_product_iterator_zip/32 -0.5844 -0.5844 162 67 162 67
flat_map::insert_product_iterator_zip/1024 -0.8754 -0.8754 3427 427 3427 427
flat_map::insert_product_iterator_zip/8192 -0.8934 -0.8934 28134 3000 28132 3000
flat_map::insert_product_iterator_zip/65536 -0.8783 -0.8783 229783 27960 229767 27958
OVERALL_GEOMEAN -0.8319 -0.8332 0 0 0 0
```
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This patch adds `static_assert` using `is_class_v` and `is_union_v` to
reject no-class type template parameters.
Fixes#132133
---------
Co-authored-by: A. Jiang <de34@live.cn>
Per [range.view]/6, a `view_interface` isn't a base class of itself, so
`enable_view` should report `false`. Also, current implementation
strategy handles `const` but not `volatile`, IIUC cv-qualifiers should
be consistent handled.
In `enable_view.compile.pass.cpp`, coverage for (`const`) `volatile`
types are added.
Drive-by: Remove one unnessary `test_macro.h` inclusion in a test.
Fixes#132577.
This is technically not necessary in most cases to prevent issues with ADL,
but let's be consistent. This allows us to remove the libcpp-qualify-declval
clang-tidy check, which is now enforced by the robust-against-adl clang-tidy check.
Some templates in the standard library are illegal to specialize for users
(even if the specialization contains user-defined types). The [[clang::no_specializations]]
attribute allows marking such base templates so that the compiler will
diagnose if users try adding a specialization.
The changes are nearly pure simplifications, so I think it's OK to do
them together in the same PR.
Actual test coverages were already added in commit ad41d1e26b12
(https://reviews.llvm.org/D141216). Thanks to Casey Carter!
Fixes#104975
Towards #105200
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.
This is necessary because e.g. ranges::elements_view uses std::get but
it needs to have in scope the declaration of all the versions of
std::get that exist in the library. This need is what had originally led
to elements_view.h gaining an include of __fwd/complex.h, but in reality
it is a more general issue that requires a canonical declration point
for all the std::get variations.
Many headers include `<cstddef>` just for size_t, and pulling in
additional content (e.g. the traits used for std::byte) is unnecessary.
To solve this problem, this patch splits up `<cstddef>` into
subcomponents so that headers can include only the parts that they
actually require.
This has the added benefit of making the modules build a lot stricter
with respect to IWYU, and also providing a canonical location where we
define `std::size_t` and friends (which were previously defined in
multiple headers like `<cstddef>` and `<ctime>`).
After this patch, there's still many places in the codebase where we
include `<cstddef>` when `<__cstddef/size_t.h>` would be sufficient.
This patch focuses on removing `<cstddef>` includes from __type_traits
to make these headers non-circular with `<cstddef>`. Additional
refactorings can be tackled separately.
## Introduction
This patch implements LWG3564:
`transform_view::iterator<true>::value_type` and `iterator_category`
should use `const F&`.
`transform_view`'s iterator currently obtained from a `const
transform_view` invoke the transformation function as `const`, but the
`value_type` and `iterator_category` determination uses non-`const`
`F&`.
## Reference
-
[[range.transform.iterator]](https://eel.is/c++draft/range.transform.iterator)
- [LWG3564](https://cplusplus.github.io/LWG/issue3564)
## Introduction
This patch implements LWG3618: Unnecessary `iter_move` for
`transform_view::iterator`.
`transform_view`'s iterator currently specifies a customization point
for `iter_move`. This customization point does the same thing that the
default implementation would do, but its sole purpose is to ensure the
appropriate conditional `noexcept` specification.
## Reference
-
[[range.transform.iterator]](https://eel.is/c++draft/range.transform.iterator)
- [LWG3618](https://cplusplus.github.io/LWG/issue3618)
As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not
being enforced in extensionless headers. This commit simply brings all
of libcxx/include in-line with clang-format again.
We might have to do this from time to time as we update our clang-format
version, but frankly this is really low effort now that we've formatted
everything once.
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>
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 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.
## Abstract
This pull request converts the `operator()` of all CPOs and niebloids
related to C++23 ranges to `static`.
## Motivation
In `libc++`, CPOs and niebloids are implemented as function objects.
Currently, the `operator()` for such a function object is a
`const`-qualified member function. This means that even if the function
object is has no data members, an extra register is used to pass in the
`this` pointer when calling `operator()`, unless the compiler can inline
the function call. Declaraing `operator()` as `static` would optimize
away the unnecessary `this` pointer passing for stateless function
objects, since there is no object instance state that needs to be
accessed.
## Reference
- [P1169R4: static `operator()`](https://wg21.link/P1169R4)
## Abstract
This pull request removes the `__workaround_52970` concept. This concept
is a workaround for a bug described in #52970, which causes the compiler
to trigger ADL on a pointer to an incomplete type in an SFINAE context.
This bug is fixed in Clang 14.
## Reference
- [[clang] Don't typo-fix an expression in a SFINAE
context](https://reviews.llvm.org/D117603)
- [[libc++] [ranges] ADL-proof the [range.access]
CPOs.](https://reviews.llvm.org/D116239)
## 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)
These headers have become very small by using compiler builtins, often
containing only two declarations. This merges these headers, since
there doesn't seem to be much of a benefit keeping them separate.
Specifically, `is_{,_nothrow,_trivially}{assignable,constructible}` are
kept and the `copy`, `move` and `default` versions of these type traits
are moved in to the respective headers.
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
We recently noticed that the unwrap_iter.h file was pushing macros, but
it was pushing them again instead of popping them at the end of the
file. This led to libc++ basically swallowing any custom definition of
these macros in user code:
#define min HELLO
#include <algorithm>
// min is not HELLO anymore, it's not defined
While investigating this issue, I noticed that our push/pop pragmas were
actually entirely wrong too. Indeed, instead of pushing macros like
`move`, we'd push `move(int, int)` in the pragma, which is not a valid
macro name. As a result, we would not actually push macros like `move`
-- instead we'd simply undefine them. This led to the following code not
working:
#define move HELLO
#include <algorithm>
// move is not HELLO anymore
Fixing the pragma push/pop incantations led to a cascade of issues
because we use identifiers like `move` in a large number of places, and
all of these headers would now need to do the push/pop dance.
This patch fixes all these issues. First, it adds a check that we don't
swallow important names like min, max, move or refresh as explained
above. This is done by augmenting the existing
system_reserved_names.gen.py test to also check that the macros are what
we expect after including each header.
Second, it fixes the push/pop pragmas to work properly and adds missing
pragmas to all the files I could detect a failure in via the newly added
test.
rdar://121365472
The tag name was long for an ABI tag. The name was misleading too, the
tag is first introduced in LLVM 18 in 2024 and not in 2023.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Also introduce `_LIBCPP_ASSERT_PEDANTIC` for assertions violating which
results in a no-op or other benign behavior, but which may nevertheless
indicate a bug in the invoking code.
fixes#70506
The detailed problem description is in #70506
The original proposed fix was to remove `[[no_unique_address]]` except
when `_Tp` is empty.
Edit:
After the discussion in the comments below, the new fix here is to
remove the `[[no_unique_address]]` from `movable_box` in the cases where
we need to add our own assignment operator, which has contains the
problematic `construct_at`
As pointed out in #72883, the implementation only needs to return the
value of ranges::next and does not need to obtain the value through
ranges::advance, which causes it to have O(n) complexity in the case
of random-access-sized but non-common range.
Fixes#72883
Currently, when libc++'s views::take specially handles an iota_view, the
addition is done after dereferencing the beginning iterator. However, in
[range.take.overview]/2.3, the addition is done before the dereferencing,
which means that the standard requires the returned iota_view to have
the same W and Bound type in such cases.
This patch fixes that, and also fixes a test that was testing the
incorrect behavior.
Fixes#75611
