maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/include/__functional/perfect_forward.h

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

96 lines
4.4 KiB
C
Raw Normal View History

[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08: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___FUNCTIONAL_PERFECT_FORWARD_H
#define _LIBCPP___FUNCTIONAL_PERFECT_FORWARD_H
#include <__config>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
#include <__utility/declval.h>
#include <__utility/forward.h>
#include <__utility/move.h>
[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08:00
#include <tuple>
#include <type_traits>
#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-02 09:16:40 +08:00
# pragma GCC system_header
[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08:00
#endif
_LIBCPP_BEGIN_NAMESPACE_STD
#if _LIBCPP_STD_VER > 14
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
template <class _Op, class _Indices, class ..._Bound>
[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08:00
struct __perfect_forward_impl;
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
template <class _Op, size_t ..._Idx, class ..._Bound>
struct __perfect_forward_impl<_Op, index_sequence<_Idx...>, _Bound...> {
private:
[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08:00
tuple<_Bound...> __bound_;
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
public:
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._BoundArgs, class = enable_if_t<
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
is_constructible_v<tuple<_Bound...>, _BoundArgs&&...>
>>
explicit constexpr __perfect_forward_impl(_BoundArgs&& ...__bound)
: __bound_(_VSTD::forward<_BoundArgs>(__bound)...)
{ }
__perfect_forward_impl(__perfect_forward_impl const&) = default;
__perfect_forward_impl(__perfect_forward_impl&&) = default;
__perfect_forward_impl& operator=(__perfect_forward_impl const&) = default;
__perfect_forward_impl& operator=(__perfect_forward_impl&&) = default;
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<is_invocable_v<_Op, _Bound&..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
_LIBCPP_HIDE_FROM_ABI constexpr auto operator()(_Args&&... __args) &
noexcept(noexcept(_Op()(_VSTD::get<_Idx>(__bound_)..., _VSTD::forward<_Args>(__args)...)))
-> decltype( _Op()(_VSTD::get<_Idx>(__bound_)..., _VSTD::forward<_Args>(__args)...))
{ return _Op()(_VSTD::get<_Idx>(__bound_)..., _VSTD::forward<_Args>(__args)...); }
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<!is_invocable_v<_Op, _Bound&..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
auto operator()(_Args&&...) & = delete;
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<is_invocable_v<_Op, _Bound const&..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
_LIBCPP_HIDE_FROM_ABI constexpr auto operator()(_Args&&... __args) const&
noexcept(noexcept(_Op()(_VSTD::get<_Idx>(__bound_)..., _VSTD::forward<_Args>(__args)...)))
-> decltype( _Op()(_VSTD::get<_Idx>(__bound_)..., _VSTD::forward<_Args>(__args)...))
{ return _Op()(_VSTD::get<_Idx>(__bound_)..., _VSTD::forward<_Args>(__args)...); }
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<!is_invocable_v<_Op, _Bound const&..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
auto operator()(_Args&&...) const& = delete;
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<is_invocable_v<_Op, _Bound..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
_LIBCPP_HIDE_FROM_ABI constexpr auto operator()(_Args&&... __args) &&
noexcept(noexcept(_Op()(_VSTD::get<_Idx>(_VSTD::move(__bound_))..., _VSTD::forward<_Args>(__args)...)))
-> decltype( _Op()(_VSTD::get<_Idx>(_VSTD::move(__bound_))..., _VSTD::forward<_Args>(__args)...))
{ return _Op()(_VSTD::get<_Idx>(_VSTD::move(__bound_))..., _VSTD::forward<_Args>(__args)...); }
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<!is_invocable_v<_Op, _Bound..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
auto operator()(_Args&&...) && = delete;
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<is_invocable_v<_Op, _Bound const..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
_LIBCPP_HIDE_FROM_ABI constexpr auto operator()(_Args&&... __args) const&&
noexcept(noexcept(_Op()(_VSTD::get<_Idx>(_VSTD::move(__bound_))..., _VSTD::forward<_Args>(__args)...)))
-> decltype( _Op()(_VSTD::get<_Idx>(_VSTD::move(__bound_))..., _VSTD::forward<_Args>(__args)...))
{ return _Op()(_VSTD::get<_Idx>(_VSTD::move(__bound_))..., _VSTD::forward<_Args>(__args)...); }
[libc++] Use enable_if_t instead of _EnableIf I just ran into a compiler error involving __bind_back and some overloads that were being disabled with _EnableIf. I noticed that the error message was quite bad and did not mention the reason for the overload being excluded. Specifically, the error looked like this: candidate template ignored: substitution failure [with _Args = <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>' Instead, when using enable_if or enable_if_t, the compiler is clever and can produce better diagnostics, like so: candidate template ignored: requirement 'is_invocable_v< std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>, std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &, ContiguousView>' was not satisfied [with _Args = <ContiguousView>] Basically, it tries to do a poor man's implementation of concepts, which is already a lot better than simply complaining about substitution failure. Hence, this commit uses enable_if_t instead of _EnableIf whenever possible. That is both more straightforward than using the internal helper, and also leads to better error messages in those cases. I understand the motivation for _EnableIf's implementation was to improve compile-time performance, however I believe striving to improve error messages is even more important for our QOI, hence this patch. Furthermore, it is unclear that _EnableIf actually improved compile-time performance in any noticeable way (see discussion in the review for details). Differential Revision: https://reviews.llvm.org/D108216
2021-08-18 00:26:09 +08:00
template <class ..._Args, class = enable_if_t<!is_invocable_v<_Op, _Bound const..., _Args...>>>
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
auto operator()(_Args&&...) const&& = delete;
[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08:00
};
[libc++] Refactor __perfect_forward, bind_front and not_fn This patch fixes the constrains on the __perfect_forward constructor and its call operators, which were incorrect. In particular, it makes sure that we closely follow [func.require], which basically says that we must deliver the bound arguments with the appropriate value category or make the call ill-formed, but not silently fall back to using a different value category. As a fly-by, this patch also: - Adds types __bind_front_t and __not_fn_t to make the result of calling bind_front and not_fn more opaque, and improve diagnostics for users. - Adds a bunch of tests for bind_front and remove some that are now redundant. - Adds some missing _LIBCPP_HIDE_FROM_ABI annotations. Immense thanks to @tcanens for raising awareness about this issue, and providing help with the = delete bits. Differential Revision: https://reviews.llvm.org/D107199
2021-07-31 02:38:14 +08:00
// __perfect_forward implements a perfect-forwarding call wrapper as explained in [func.require].
template <class _Op, class ..._Args>
using __perfect_forward = __perfect_forward_impl<_Op, index_sequence_for<_Args...>, _Args...>;
[libcxx][functional][modular] splices <functional> into modular headers Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 21:25:35 +08:00
#endif // _LIBCPP_STD_VER > 14
_LIBCPP_END_NAMESPACE_STD
#endif // _LIBCPP___FUNCTIONAL_PERFECT_FORWARD_H