mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-29 22:36:05 +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.

243 lines
7.5 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>
struct __pointer_traits_element_type;
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
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;
};
template <class _Ptr>
struct _LIBCPP_TEMPLATE_VIS pointer_traits
{
typedef _Ptr pointer;
typedef typename __pointer_traits_element_type<pointer>::type element_type;
typedef typename __pointer_traits_difference_type<pointer>::type difference_type;
#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 {};
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_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX20
[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
static pointer 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);}
};
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 {};
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_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX20
[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
static pointer 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 _VSTD::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_INLINE_VISIBILITY _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>
struct _HasToAddress<_Pointer,
decltype((void)pointer_traits<_Pointer>::to_address(declval<const _Pointer&>()))
> : true_type {};
template <class _Pointer, class = void>
struct _HasArrow : false_type {};
template <class _Pointer>
struct _HasArrow<_Pointer,
decltype((void)declval<const _Pointer&>().operator->())
> : true_type {};
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++][NFC] Rename _EnableIf to __enable_if_t for consistency In other places in the code, we use lowercase spelling for things that are not available in prior standards. Differential Revision: https://reviews.llvm.org/D109435
2021-09-08 09:14:43 -04:00
template <class _Pointer, class = __enable_if_t<
[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
_And<is_class<_Pointer>, _IsFancyPointer<_Pointer> >::value
[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
> >
[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_INLINE_VISIBILITY _LIBCPP_CONSTEXPR
typename decay<decltype(__to_address_helper<_Pointer>::__call(declval<const _Pointer&>()))>::type
__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_INLINE_VISIBILITY _LIBCPP_CONSTEXPR
static decltype(_VSTD::__to_address(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 _VSTD::__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>
struct __to_address_helper<_Pointer, decltype((void)pointer_traits<_Pointer>::to_address(declval<const _Pointer&>()))> {
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR
static decltype(pointer_traits<_Pointer>::to_address(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++] 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
#if _LIBCPP_STD_VER > 17
[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_INLINE_VISIBILITY constexpr
auto to_address(_Tp *__p) noexcept {
return _VSTD::__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>
inline _LIBCPP_INLINE_VISIBILITY constexpr
[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
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 _VSTD::__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