mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-29 15:46:08 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/libcxx/include/__memory/pointer_traits.h

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

246 lines
7.6 KiB
C
Raw Normal View History

[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
// -*- C++ -*-
//===----------------------------------------------------------------------===//
//
// 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 _LIBCPP___MEMORY_POINTER_TRAITS_H
#define _LIBCPP___MEMORY_POINTER_TRAITS_H
#include <__config>
[libcxx][iwyu] ensures we IWYU as prep for modules This has been broken out of D104170 since it should be merged whether or not we go ahead with the module map changes. Differential Revision: https://reviews.llvm.org/D104175
2021-06-12 06:13:44 +00:00
#include <__memory/addressof.h>
[libc++] Granularize <type_traits> includes in <compare> Reviewed By: Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D140480
2022-12-21 00:07:17 +01:00
#include <__type_traits/conditional.h>
#include <__type_traits/conjunction.h>
#include <__type_traits/decay.h>
#include <__type_traits/is_class.h>
#include <__type_traits/is_function.h>
#include <__type_traits/is_void.h>
#include <__type_traits/void_t.h>
#include <__utility/declval.h>
[libc++] Add missing includes of <cstddef>
2022-08-10 11:34:31 -04:00
#include <cstddef>
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
[libc++] Normalize all our '#pragma GCC system_header', and regression-test. Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800
2022-02-01 20:16:40 -05:00
# pragma GCC system_header
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#endif
_LIBCPP_BEGIN_NAMESPACE_STD
template <class _Tp, class = void>
struct __has_element_type : false_type {};
template <class _Tp>
[libc++][NFC] Prefer type aliases over structs Reviewed By: ldionne, #libc Spies: sstefan1, libcxx-commits, jeroen.dobbelaere Differential Revision: https://reviews.llvm.org/D134901
2022-10-01 15:42:00 +02:00
struct __has_element_type<_Tp, __void_t<typename _Tp::element_type> > : true_type {};
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
template <class _Ptr, bool = __has_element_type<_Ptr>::value>
[libc++] Implement LWG3545: std::pointer_traits should be SFINAE-friendly. (#65177) See https://wg21.link/LWG3545 for background and details. Differential Revision: https://reviews.llvm.org/D158922
2023-09-18 05:46:59 -07:00
struct __pointer_traits_element_type {};
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
template <class _Ptr>
struct __pointer_traits_element_type<_Ptr, true> {
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Ptr::element_type type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
};
template <template <class, class...> class _Sp, class _Tp, class... _Args>
struct __pointer_traits_element_type<_Sp<_Tp, _Args...>, true> {
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Sp<_Tp, _Args...>::element_type type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
};
template <template <class, class...> class _Sp, class _Tp, class... _Args>
struct __pointer_traits_element_type<_Sp<_Tp, _Args...>, false> {
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG _Tp type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
};
template <class _Tp, class = void>
struct __has_difference_type : false_type {};
template <class _Tp>
[libc++][NFC] Prefer type aliases over structs Reviewed By: ldionne, #libc Spies: sstefan1, libcxx-commits, jeroen.dobbelaere Differential Revision: https://reviews.llvm.org/D134901
2022-10-01 15:42:00 +02:00
struct __has_difference_type<_Tp, __void_t<typename _Tp::difference_type> > : true_type {};
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
template <class _Ptr, bool = __has_difference_type<_Ptr>::value>
struct __pointer_traits_difference_type {
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG ptrdiff_t type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
};
template <class _Ptr>
struct __pointer_traits_difference_type<_Ptr, true> {
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Ptr::difference_type type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
};
template <class _Tp, class _Up>
struct __has_rebind {
private:
[libc++] Remove uses of __two in type_traits Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D127483
2022-06-10 12:42:46 +02:00
template <class _Xp>
static false_type __test(...);
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
_LIBCPP_SUPPRESS_DEPRECATED_PUSH
[libc++] Remove uses of __two in type_traits Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D127483
2022-06-10 12:42:46 +02:00
template <class _Xp>
static true_type __test(typename _Xp::template rebind<_Up>* = 0);
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
_LIBCPP_SUPPRESS_DEPRECATED_POP
[libc++] Format the code base (#74334) This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-18 14:01:33 -05:00
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
public:
[libc++] Remove uses of __two in type_traits Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D127483
2022-06-10 12:42:46 +02:00
static const bool value = decltype(__test<_Tp>(0))::value;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
};
template <class _Tp, class _Up, bool = __has_rebind<_Tp, _Up>::value>
struct __pointer_traits_rebind {
#ifndef _LIBCPP_CXX03_LANG
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Tp::template rebind<_Up> type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#else
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Tp::template rebind<_Up>::other type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#endif
};
template <template <class, class...> class _Sp, class _Tp, class... _Args, class _Up>
struct __pointer_traits_rebind<_Sp<_Tp, _Args...>, _Up, true> {
#ifndef _LIBCPP_CXX03_LANG
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Sp<_Tp, _Args...>::template rebind<_Up> type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#else
[libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs Clang used to support [[nodebug]] everywhere except on typedefs. Since we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE in favour of always using _LIBCPP_NODEBUG. Differential Revision: https://reviews.llvm.org/D108996
2021-08-31 10:32:11 -04:00
typedef _LIBCPP_NODEBUG typename _Sp<_Tp, _Args...>::template rebind<_Up>::other type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#endif
};
template <template <class, class...> class _Sp, class _Tp, class... _Args, class _Up>
struct __pointer_traits_rebind<_Sp<_Tp, _Args...>, _Up, false> {
typedef _Sp<_Up, _Args...> type;
};
[libc++] Implement LWG3545: std::pointer_traits should be SFINAE-friendly. (#65177) See https://wg21.link/LWG3545 for background and details. Differential Revision: https://reviews.llvm.org/D158922
2023-09-18 05:46:59 -07:00
template <class _Ptr, class = void>
struct __pointer_traits_impl {};
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
template <class _Ptr>
[libc++] Implement LWG3545: std::pointer_traits should be SFINAE-friendly. (#65177) See https://wg21.link/LWG3545 for background and details. Differential Revision: https://reviews.llvm.org/D158922
2023-09-18 05:46:59 -07:00
struct __pointer_traits_impl<_Ptr, __void_t<typename __pointer_traits_element_type<_Ptr>::type> > {
typedef _Ptr pointer;
typedef typename __pointer_traits_element_type<pointer>::type element_type;
typedef typename __pointer_traits_difference_type<pointer>::type difference_type;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#ifndef _LIBCPP_CXX03_LANG
template <class _Up>
using rebind = typename __pointer_traits_rebind<pointer, _Up>::type;
#else
template <class _Up>
struct rebind {
typedef typename __pointer_traits_rebind<pointer, _Up>::type other;
};
[libc++] NFC: Normalize `#endif //` comment indentation
2021-04-20 12:03:32 -04:00
#endif // _LIBCPP_CXX03_LANG
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
private:
struct __nat {};
[libc++] Format the code base (#74334) This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-18 14:01:33 -05:00
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
public:
[libc++][NFC] Rename the constexpr macros This was discussed on Discord with the consensus that we should rename the macros. Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D131498
2022-08-19 13:08:01 +02:00
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 static pointer
[libc++][NFC] Prefer type aliases over structs Reviewed By: ldionne, #libc Spies: sstefan1, libcxx-commits, jeroen.dobbelaere Differential Revision: https://reviews.llvm.org/D134901
2022-10-01 15:42:00 +02:00
pointer_to(__conditional_t<is_void<element_type>::value, __nat, element_type>& __r) {
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
return pointer::pointer_to(__r);
}
};
[libc++] Implement LWG3545: std::pointer_traits should be SFINAE-friendly. (#65177) See https://wg21.link/LWG3545 for background and details. Differential Revision: https://reviews.llvm.org/D158922
2023-09-18 05:46:59 -07:00
template <class _Ptr>
struct _LIBCPP_TEMPLATE_VIS pointer_traits : __pointer_traits_impl<_Ptr> {};
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
template <class _Tp>
struct _LIBCPP_TEMPLATE_VIS pointer_traits<_Tp*> {
typedef _Tp* pointer;
typedef _Tp element_type;
typedef ptrdiff_t difference_type;
#ifndef _LIBCPP_CXX03_LANG
template <class _Up>
using rebind = _Up*;
#else
template <class _Up>
struct rebind {
typedef _Up* other;
};
#endif
private:
struct __nat {};
[libc++] Format the code base (#74334) This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-18 14:01:33 -05:00
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
public:
[libc++][NFC] Rename the constexpr macros This was discussed on Discord with the consensus that we should rename the macros. Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D131498
2022-08-19 13:08:01 +02:00
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 static pointer
[libc++][NFC] Prefer type aliases over structs Reviewed By: ldionne, #libc Spies: sstefan1, libcxx-commits, jeroen.dobbelaere Differential Revision: https://reviews.llvm.org/D134901
2022-10-01 15:42:00 +02:00
pointer_to(__conditional_t<is_void<element_type>::value, __nat, element_type>& __r) _NOEXCEPT {
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
return std::addressof(__r);
}
};
#ifndef _LIBCPP_CXX03_LANG
[libc++] Avoid instantiating type_trait classes Use `using` aliases to avoid instantiating lots of types Reviewed By: ldionne, #libc Spies: libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D132785
2022-09-06 00:33:34 +02:00
template <class _From, class _To>
using __rebind_pointer_t = typename pointer_traits<_From>::template rebind<_To>;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#else
[libc++] Avoid instantiating type_trait classes Use `using` aliases to avoid instantiating lots of types Reviewed By: ldionne, #libc Spies: libcxx-commits, miyuki Differential Revision: https://reviews.llvm.org/D132785
2022-09-06 00:33:34 +02:00
template <class _From, class _To>
using __rebind_pointer_t = typename pointer_traits<_From>::template rebind<_To>::other;
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
#endif
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
// to_address
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
template <class _Pointer, class = void>
struct __to_address_helper;
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
template <class _Tp>
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR _Tp* __to_address(_Tp* __p) _NOEXCEPT {
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
static_assert(!is_function<_Tp>::value, "_Tp is a function type");
return __p;
}
[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`. Evaluating `contiguous_iterator` on an iterator that satisfies all the constraints except the `to_address` constraint and doesn't have `operator->` defined results in a hard error. This is because instantiating `to_address` ends up instantiating templates dependent on the given type which might lead to a hard error even in a SFINAE context. Differential Revision: https://reviews.llvm.org/D130835
2022-08-04 10:57:58 -07:00
template <class _Pointer, class = void>
struct _HasToAddress : false_type {};
template <class _Pointer>
[libc++][NFC] Qualify declval While it's not necessary to qualify calls to `declval` it makes error messages very crypric if the declaration isn't reachable anymore For example: ``` /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<long, long>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>, std::chrono::duration<long, std::ratio<3600, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:280:81: error: no type named 'type' in 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator-() const {return typename common_type<duration>::type(-__rep_);} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<int, int>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>, std::chrono::duration<int, std::ratio<86400, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:309:55: note: in instantiation of template class 'std::chrono::duration<int, std::ratio<86400, 1>>' requested here typedef duration< int, ratio_multiply<ratio<7>, days::period>> weeks; ^ 19 similar errors omitted ``` changes with qualification added to: ``` While building module 'std' imported from /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13: In file included from <module-includes>:17: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/math.h:309: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/limits:107: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/type_traits:432: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_reference.h:13: /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:28:43: error: declaration of 'declval' must be imported from module 'std.utility.__utility.declval' before it is required using __cond_type = decltype(false ? std::declval<_Tp>() : std::declval<_Up>()); ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__utility/declval.h:30:34: note: declaration here is not visible decltype(std::__declval<_Tp>(0)) declval() _NOEXCEPT; ^ /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:10: fatal error: could not build module 'std' #include <functional> ~~~~~~~~^ 2 errors generated. ``` Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D130854
2022-07-31 21:54:25 +02:00
struct _HasToAddress<_Pointer, decltype((void)pointer_traits<_Pointer>::to_address(std::declval<const _Pointer&>())) >
[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`. Evaluating `contiguous_iterator` on an iterator that satisfies all the constraints except the `to_address` constraint and doesn't have `operator->` defined results in a hard error. This is because instantiating `to_address` ends up instantiating templates dependent on the given type which might lead to a hard error even in a SFINAE context. Differential Revision: https://reviews.llvm.org/D130835
2022-08-04 10:57:58 -07:00
: true_type {};
template <class _Pointer, class = void>
struct _HasArrow : false_type {};
template <class _Pointer>
[libc++][NFC] Qualify declval While it's not necessary to qualify calls to `declval` it makes error messages very crypric if the declaration isn't reachable anymore For example: ``` /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<long, long>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>, std::chrono::duration<long, std::ratio<3600, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:280:81: error: no type named 'type' in 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator-() const {return typename common_type<duration>::type(-__rep_);} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<int, int>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>, std::chrono::duration<int, std::ratio<86400, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:309:55: note: in instantiation of template class 'std::chrono::duration<int, std::ratio<86400, 1>>' requested here typedef duration< int, ratio_multiply<ratio<7>, days::period>> weeks; ^ 19 similar errors omitted ``` changes with qualification added to: ``` While building module 'std' imported from /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13: In file included from <module-includes>:17: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/math.h:309: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/limits:107: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/type_traits:432: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_reference.h:13: /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:28:43: error: declaration of 'declval' must be imported from module 'std.utility.__utility.declval' before it is required using __cond_type = decltype(false ? std::declval<_Tp>() : std::declval<_Up>()); ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__utility/declval.h:30:34: note: declaration here is not visible decltype(std::__declval<_Tp>(0)) declval() _NOEXCEPT; ^ /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:10: fatal error: could not build module 'std' #include <functional> ~~~~~~~~^ 2 errors generated. ``` Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D130854
2022-07-31 21:54:25 +02:00
struct _HasArrow<_Pointer, decltype((void)std::declval<const _Pointer&>().operator->()) > : true_type {};
[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`. Evaluating `contiguous_iterator` on an iterator that satisfies all the constraints except the `to_address` constraint and doesn't have `operator->` defined results in a hard error. This is because instantiating `to_address` ends up instantiating templates dependent on the given type which might lead to a hard error even in a SFINAE context. Differential Revision: https://reviews.llvm.org/D130835
2022-08-04 10:57:58 -07:00
template <class _Pointer>
struct _IsFancyPointer {
static const bool value = _HasArrow<_Pointer>::value || _HasToAddress<_Pointer>::value;
};
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
// enable_if is needed here to avoid instantiating checks for fancy pointers on raw pointers
[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`. Evaluating `contiguous_iterator` on an iterator that satisfies all the constraints except the `to_address` constraint and doesn't have `operator->` defined results in a hard error. This is because instantiating `to_address` ends up instantiating templates dependent on the given type which might lead to a hard error even in a SFINAE context. Differential Revision: https://reviews.llvm.org/D130835
2022-08-04 10:57:58 -07:00
template <class _Pointer, class = __enable_if_t< _And<is_class<_Pointer>, _IsFancyPointer<_Pointer> >::value > >
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR
[libc++] Add __decay_t and use it instead of decay<>::type This avoids instantiating lots of types. Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D146984
2023-03-27 18:22:23 +02:00
__decay_t<decltype(__to_address_helper<_Pointer>::__call(std::declval<const _Pointer&>()))>
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
__to_address(const _Pointer& __p) _NOEXCEPT {
return __to_address_helper<_Pointer>::__call(__p);
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
}
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
template <class _Pointer, class>
struct __to_address_helper {
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR static decltype(std::__to_address(
[libc++][NFC] Qualify declval While it's not necessary to qualify calls to `declval` it makes error messages very crypric if the declaration isn't reachable anymore For example: ``` /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<long, long>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>, std::chrono::duration<long, std::ratio<3600, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:280:81: error: no type named 'type' in 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator-() const {return typename common_type<duration>::type(-__rep_);} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<int, int>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>, std::chrono::duration<int, std::ratio<86400, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:309:55: note: in instantiation of template class 'std::chrono::duration<int, std::ratio<86400, 1>>' requested here typedef duration< int, ratio_multiply<ratio<7>, days::period>> weeks; ^ 19 similar errors omitted ``` changes with qualification added to: ``` While building module 'std' imported from /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13: In file included from <module-includes>:17: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/math.h:309: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/limits:107: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/type_traits:432: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_reference.h:13: /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:28:43: error: declaration of 'declval' must be imported from module 'std.utility.__utility.declval' before it is required using __cond_type = decltype(false ? std::declval<_Tp>() : std::declval<_Up>()); ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__utility/declval.h:30:34: note: declaration here is not visible decltype(std::__declval<_Tp>(0)) declval() _NOEXCEPT; ^ /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:10: fatal error: could not build module 'std' #include <functional> ~~~~~~~~^ 2 errors generated. ``` Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D130854
2022-07-31 21:54:25 +02:00
std::declval<const _Pointer&>().operator->()))
[libc++] Add missing space in (__map_value_compare&__y) etc. NFCI.
2021-08-31 14:29:24 -04:00
__call(const _Pointer& __p) _NOEXCEPT {
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
return std::__to_address(__p.operator->());
}
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
};
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
template <class _Pointer>
[libc++][NFC] Qualify declval While it's not necessary to qualify calls to `declval` it makes error messages very crypric if the declaration isn't reachable anymore For example: ``` /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<long, long>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>, std::chrono::duration<long, std::ratio<3600, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:280:81: error: no type named 'type' in 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator-() const {return typename common_type<duration>::type(-__rep_);} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<int, int>' typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>, std::chrono::duration<int, std::ratio<86400, 1>>>' requested here : public common_type<_Tp, _Tp> {}; ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>>' requested here _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);} ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:309:55: note: in instantiation of template class 'std::chrono::duration<int, std::ratio<86400, 1>>' requested here typedef duration< int, ratio_multiply<ratio<7>, days::period>> weeks; ^ 19 similar errors omitted ``` changes with qualification added to: ``` While building module 'std' imported from /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13: In file included from <module-includes>:17: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/math.h:309: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/limits:107: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/type_traits:432: In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_reference.h:13: /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:28:43: error: declaration of 'declval' must be imported from module 'std.utility.__utility.declval' before it is required using __cond_type = decltype(false ? std::declval<_Tp>() : std::declval<_Up>()); ^ /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__utility/declval.h:30:34: note: declaration here is not visible decltype(std::__declval<_Tp>(0)) declval() _NOEXCEPT; ^ /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:10: fatal error: could not build module 'std' #include <functional> ~~~~~~~~^ 2 errors generated. ``` Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D130854
2022-07-31 21:54:25 +02:00
struct __to_address_helper<_Pointer,
decltype((void)pointer_traits<_Pointer>::to_address(std::declval<const _Pointer&>()))> {
_LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR static decltype(pointer_traits<_Pointer>::to_address(
std::declval<const _Pointer&>()))
[libc++] Add missing space in (__map_value_compare&__y) etc. NFCI.
2021-08-31 14:29:24 -04:00
__call(const _Pointer& __p) _NOEXCEPT {
[libc++] Rewrite std::to_address to avoid relying on element_type This is a rough reapplication of the change that fixed std::to_address to avoid relying on element_type (da456167). It is somewhat different because the fix to avoid breaking Clang (which caused it to be reverted in 347f69c55) was a bit more involved. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:51:58 -04:00
return pointer_traits<_Pointer>::to_address(__p);
}
};
[libc++] Revert the std::to_address change to avoid relying on element_type. This reverts commit da456167, which broke the Clang build. I'm able to reproduce it but I want to give myself a bit more time to investigate. Differential Revision: https://reviews.llvm.org/D101638
2021-05-04 18:48:16 -04:00
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962
2023-02-14 00:56:09 +01:00
#if _LIBCPP_STD_VER >= 20
[libc++] Fix std::to_address(array). There were basically two bugs here: When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes a reference to a const array, and then we dispatch to `__to_address<const int(&)[10]>`, which, oops, gives us a `const int*` result instead of an `int*` result. Solution: We need to provide the two standard-specified overloads of `std::to_address` in exactly the same way that we provide two overloads of `__to_address`. When `__to_address` is called on a pointer type, `__to_address(const _Ptr&)` is disabled so we successfully avoid trying to instantiate pointer_traits of that pointer type. But when it's called on an array type, it's not disabled for array types, so we go ahead and instantiate pointer_traits<int[10]>, which goes boom. Solution: We need to disable `__to_address(const _Ptr&)` for both pointer and array types. Also disable it for function types, so that they get the nice error message; and put a test on it. Differential Revision: https://reviews.llvm.org/D109331
2021-09-06 14:11:45 -04:00
template <class _Tp>
inline _LIBCPP_HIDE_FROM_ABI constexpr auto to_address(_Tp* __p) noexcept {
return std::__to_address(__p);
}
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
template <class _Pointer>
[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`. Evaluating `contiguous_iterator` on an iterator that satisfies all the constraints except the `to_address` constraint and doesn't have `operator->` defined results in a hard error. This is because instantiating `to_address` ends up instantiating templates dependent on the given type which might lead to a hard error even in a SFINAE context. Differential Revision: https://reviews.llvm.org/D130835
2022-08-04 10:57:58 -07:00
inline _LIBCPP_HIDE_FROM_ABI constexpr auto to_address(const _Pointer& __p) noexcept
-> decltype(std::__to_address(__p)) {
[libc++] Rationalize our treatment of contiguous iterators and __unwrap_iter(). - Implement C++20's changes to `reverse_iterator`, so that it won't be accidentally counted as a contiguous iterator in C++20 mode. - Implement C++20's changes to `move_iterator` as well. - `move_iterator` should not be contiguous. This fixes a bug where we optimized `std::copy`-of-move-iterators in an observable way. Add a regression test for that bugfix. - Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant standard iterator types. Particularly check that vector::iterator is still considered contiguous in all C++ modes, even C++03. After this patch, there continues to be no supported way to write your own iterator type in C++17-and-earlier such that libc++ will consider it "contiguous"; however, we now fully support the C++20 approach (in C++20 mode only). If you want user-defined contiguous iterators in C++17-and-earlier, libc++'s position is "please upgrade to C++20." Differential Revision: https://reviews.llvm.org/D94807
2021-01-15 12:59:56 -05:00
return std::__to_address(__p);
}
#endif
[libc++] Split allocator_traits and pointer_traits out of <memory> In addition to making the code a lot easier to grasp by localizing many helper functions to the only file where they are actually needed, this will allow creating helper functions that depend on allocator_traits outside of <memory>. This is done as part of implementing array support in allocate_shared, which requires non-trivial array initialization algorithms that would be better to keep out of <memory> for sanity. It's also a first step towards splitting up our monolithic headers into finer grained ones, which will make it easier to reuse functionality across the library. For example, it's just weird that we had to define `addressof` inside <type_traits> to avoid circular dependencies -- instead it's better to implement those in true helper headers. Differential Revision: https://reviews.llvm.org/D93074
2020-12-10 18:28:13 -05:00
_LIBCPP_END_NAMESPACE_STD
[libc++] NFC: Normalize `#endif //` comment indentation
2021-04-20 12:03:32 -04:00
#endif // _LIBCPP___MEMORY_POINTER_TRAITS_H
Reference in New Issue Copy Permalink