llvm-project/libcxx/test/std/containers/from_range_helpers.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

118 lines
3.4 KiB
C
Raw Normal View History

//===----------------------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#ifndef SUPPORT_FROM_RANGE_HELPERS_H
#define SUPPORT_FROM_RANGE_HELPERS_H
[libc++][test] Fix assumptions that `std::array` iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where `std::array` iterators are never pointers. Most of these changes are reasonably self-explanatory (the `std::array`s are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In `libcxx/test/std/containers/from_range_helpers.h`, `wrap_input()` is called with `Iter` types that are constructible from raw pointers. It's also sometimes called with an `array` as the `input`, so the first overload was implicitly assuming that `array` iterators are pointers. We can fix this assumption by providing a dedicated overload for `array`, just like the one for `vector` immediately below. Finally, `from_range_helpers.h` should explicitly include both `<array>` and `<vector>`, even though they were apparently being dragged in already. In `libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp`, fix `throw_operator_minus`. The error was pretty complicated, caused by the concepts machinery noticing that `value_type` and `element_type` were inconsistent. In the template instantiation context, you can see the critical detail that `throw_operator_minus<std::_Array_iterator>` is being formed. Fortunately, the fix is extremely simple. To produce `element_type` (which retains any cv-qualification, unlike `value_type`), we shouldn't attempt to `remove_pointer` with the iterator type `It`. Instead, we've already obtained the `reference` type, so we can `remove_reference_t`. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.)
2023-12-05 08:25:42 -08:00
#include <array>
#include <cstddef>
#include <iterator>
#include <type_traits>
[libc++][test] Fix assumptions that `std::array` iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where `std::array` iterators are never pointers. Most of these changes are reasonably self-explanatory (the `std::array`s are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In `libcxx/test/std/containers/from_range_helpers.h`, `wrap_input()` is called with `Iter` types that are constructible from raw pointers. It's also sometimes called with an `array` as the `input`, so the first overload was implicitly assuming that `array` iterators are pointers. We can fix this assumption by providing a dedicated overload for `array`, just like the one for `vector` immediately below. Finally, `from_range_helpers.h` should explicitly include both `<array>` and `<vector>`, even though they were apparently being dragged in already. In `libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp`, fix `throw_operator_minus`. The error was pretty complicated, caused by the concepts machinery noticing that `value_type` and `element_type` were inconsistent. In the template instantiation context, you can see the critical detail that `throw_operator_minus<std::_Array_iterator>` is being formed. Fortunately, the fix is extremely simple. To produce `element_type` (which retains any cv-qualification, unlike `value_type`), we shouldn't attempt to `remove_pointer` with the iterator type `It`. Instead, we've already obtained the `reference` type, so we can `remove_reference_t`. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.)
2023-12-05 08:25:42 -08:00
#include <vector>
#include "min_allocator.h"
#include "test_allocator.h"
#include "test_iterators.h"
#include "test_macros.h"
#include "type_algorithms.h"
struct Empty {};
template <class T>
struct InputRange {
cpp20_input_iterator<T*> begin();
sentinel_wrapper<cpp20_input_iterator<T*>> end();
};
template <class Iter, class Sent, std::ranges::input_range Range>
constexpr auto wrap_input(Range&& input) {
auto b = Iter(std::ranges::begin(input));
auto e = Sent(Iter(std::ranges::end(input)));
return std::ranges::subrange(std::move(b), std::move(e));
}
[libc++][test] Fix assumptions that `std::array` iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where `std::array` iterators are never pointers. Most of these changes are reasonably self-explanatory (the `std::array`s are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In `libcxx/test/std/containers/from_range_helpers.h`, `wrap_input()` is called with `Iter` types that are constructible from raw pointers. It's also sometimes called with an `array` as the `input`, so the first overload was implicitly assuming that `array` iterators are pointers. We can fix this assumption by providing a dedicated overload for `array`, just like the one for `vector` immediately below. Finally, `from_range_helpers.h` should explicitly include both `<array>` and `<vector>`, even though they were apparently being dragged in already. In `libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp`, fix `throw_operator_minus`. The error was pretty complicated, caused by the concepts machinery noticing that `value_type` and `element_type` were inconsistent. In the template instantiation context, you can see the critical detail that `throw_operator_minus<std::_Array_iterator>` is being formed. Fortunately, the fix is extremely simple. To produce `element_type` (which retains any cv-qualification, unlike `value_type`), we shouldn't attempt to `remove_pointer` with the iterator type `It`. Instead, we've already obtained the `reference` type, so we can `remove_reference_t`. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.)
2023-12-05 08:25:42 -08:00
template <class Iter, class Sent, class T, std::size_t N>
constexpr auto wrap_input(std::array<T, N>& input) {
auto b = Iter(input.data());
auto e = Sent(Iter(input.data() + input.size()));
return std::ranges::subrange(std::move(b), std::move(e));
}
template <class Iter, class Sent, class T>
constexpr auto wrap_input(std::vector<T>& input) {
auto b = Iter(input.data());
auto e = Sent(Iter(input.data() + input.size()));
return std::ranges::subrange(std::move(b), std::move(e));
}
struct KeyValue {
int key; // Only the key is considered for equality comparison.
char value; // Allows distinguishing equivalent instances.
bool operator<(const KeyValue& other) const { return key < other.key; }
bool operator==(const KeyValue& other) const { return key == other.key; }
};
template <>
struct std::hash<KeyValue> {
std::size_t operator()(const KeyValue& kv) const {
return kv.key;
}
};
#if !defined(TEST_HAS_NO_EXCEPTIONS)
template <class T>
struct ThrowingAllocator {
using value_type = T;
using char_type = T;
using is_always_equal = std::false_type;
ThrowingAllocator() = default;
template <class U>
ThrowingAllocator(const ThrowingAllocator<U>&) {}
T* allocate(std::size_t) { throw 1; }
void deallocate(T*, std::size_t) {}
template <class U>
friend bool operator==(const ThrowingAllocator&, const ThrowingAllocator<U>&) {
return true;
}
};
#endif
template <class T, class Func>
constexpr void for_all_iterators_and_allocators(Func f) {
using Iterators = types::type_list<
cpp20_input_iterator<T*>,
forward_iterator<T*>,
bidirectional_iterator<T*>,
random_access_iterator<T*>,
contiguous_iterator<T*>,
T*
>;
types::for_each(Iterators{}, [=]<class Iter>() {
f.template operator()<Iter, sentinel_wrapper<Iter>, std::allocator<T>>();
f.template operator()<Iter, sentinel_wrapper<Iter>, test_allocator<T>>();
f.template operator()<Iter, sentinel_wrapper<Iter>, min_allocator<T>>();
f.template operator()<Iter, sentinel_wrapper<Iter>, safe_allocator<T>>();
if constexpr (std::sentinel_for<Iter, Iter>) {
f.template operator()<Iter, Iter, std::allocator<T>>();
f.template operator()<Iter, Iter, test_allocator<T>>();
f.template operator()<Iter, Iter, min_allocator<T>>();
f.template operator()<Iter, Iter, safe_allocator<T>>();
}
});
}
#endif // SUPPORT_FROM_RANGE_HELPERS_H