[libc++] Verifies std::forward_like's mandates clause. #127318
Conversation
The existing using _ForwardLike declaration already fails with a subsitution failure. The LWG issue was filed to clarify what should happen for non-referencable types. Added test to verify libc++ is alrady enforcing the new mandates. Implements: - LWG3757 What's the effect of std::forward_like<void>(x) Closes: llvm#105026
llvmbot
added
the
libc++
|
@llvm/pr-subscribers-libcxx Author: Mark de Wever (mordante) ChangesThe existing using _ForwardLike declaration already fails with a subsitution failure. The LWG issue was filed to clarify what should happen for non-referencable types. Added test to verify libc++ is alrady enforcing the new mandates. Implements:
Closes: #105026 Full diff: https://github.com/llvm/llvm-project/pull/127318.diff 2 Files Affected:
diff --git a/libcxx/docs/Status/Cxx23Issues.csv b/libcxx/docs/Status/Cxx23Issues.csv
index 1215f21985eb9..6471fdbf069a3 100644
--- a/libcxx/docs/Status/Cxx23Issues.csv
+++ b/libcxx/docs/Status/Cxx23Issues.csv
@@ -213,7 +213,7 @@
"`LWG3753 <https://wg21.link/LWG3753>`__","Clarify entity vs. freestanding entity","2022-11 (Kona)","","",""
"`LWG3754 <https://wg21.link/LWG3754>`__","Class template expected synopsis contains declarations that do not match the detailed description","2022-11 (Kona)","|Nothing To Do|","",""
"`LWG3755 <https://wg21.link/LWG3755>`__","``tuple-for-each`` can call ``user-defined`` ``operator,``","2022-11 (Kona)","|Complete|","17",""
-"`LWG3757 <https://wg21.link/LWG3757>`__","What's the effect of ``std::forward_like<void>(x)``?","2022-11 (Kona)","","",""
+"`LWG3757 <https://wg21.link/LWG3757>`__","What's the effect of ``std::forward_like<void>(x)``?","2022-11 (Kona)","|Nothing To Do|","",""
"`LWG3759 <https://wg21.link/LWG3759>`__","``ranges::rotate_copy`` should use ``std::move``","2022-11 (Kona)","|Complete|","15",""
"`LWG3760 <https://wg21.link/LWG3760>`__","``cartesian_product_view::iterator``'s ``parent_`` is never valid","2022-11 (Kona)","","",""
"`LWG3761 <https://wg21.link/LWG3761>`__","``cartesian_product_view::iterator::operator-`` should pass by reference","2022-11 (Kona)","","",""
diff --git a/libcxx/test/std/utilities/utility/forward/forward_like.verify.cpp b/libcxx/test/std/utilities/utility/forward/forward_like.verify.cpp
new file mode 100644
index 0000000000000..279f0e60a1c38
--- /dev/null
+++ b/libcxx/test/std/utilities/utility/forward/forward_like.verify.cpp
@@ -0,0 +1,46 @@
+//===----------------------------------------------------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+// REQUIRES: std-at-least-c++23
+
+// <utility>
+
+// template <typename T>
+// [[nodiscard]] constexpr
+// auto forward_like(auto&& x) noexcept -> see below;
+
+// Mandates: T is a referenceable type (3.45 [defns.referenceable]).
+
+#include <utility>
+
+struct incomplete;
+
+void test() {
+ int i;
+ (void)std::forward_like<incomplete>(i);
+
+ (void)std::forward_like<void>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<const void>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<volatile void>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<const volatile void>(i); // expected-error {{no matching function for call to 'forward_like'}}
+
+ using fp = void();
+ using cfp = void() const;
+ using vfp = void() volatile;
+ using cvfp = void() const volatile;
+ (void)std::forward_like<fp>(i);
+ (void)std::forward_like<cfp>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<cfp>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<vfp>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<cvfp>(i); // expected-error {{no matching function for call to 'forward_like'}}
+
+ using fpr = void()&;
+ using fprr = void()&&;
+ (void)std::forward_like<fpr>(i); // expected-error {{no matching function for call to 'forward_like'}}
+ (void)std::forward_like<fprr>(i); // expected-error {{no matching function for call to 'forward_like'}}
+}
|
I don't think we can. With SFINAE we test a constraint clause and this is a mandates clause. |
Yeah, I'm actually not convinced this is "nothing to do". We're currently SFINAEing away AFAICT, but the standard asks us to reject the code out right. |
Since there's only one It's not very clear to me what should happen when user-provided overloads are involved... |
Indeed, that's why I added tests to make sure the SFINAE acts as a mandates.
AFAIK they are not allowed to do that. |
Oh, sorry for causing misunderstanding. I meant something like the following, not user-provided using std::forward_like;
using nonstd::forward_like;
forward_like<void>(x); // Should std::forward_like catch this and cause error? |
Can we instead refactor the code to not SFINAE away? I'd be much happier with that, since it avoids portability issues and |
What portability issues do you expect? I had a look at your suggestion and it's not that trivial, adding a constrained overload with a dummy return type fails due to Clang being unhappy with the function signature. Clang has some diagnostics related to certain Standard library functions and types. |
There was a problem hiding this comment.
I think Nikolas' point is that if we implement a Mandates as SFINAE, that's something that users can rely on to disable their own overloads. But if we switched to a static_assert instead, their code would start failing with a hard error. So in that way, implementing a Mandates with a static_assert is stricter and "closer to the strict interpretation of the spec".
I would also rather implement this Mandates as a static_assert if we can: for example we could add the following to the body of __forward_like:
static_assert(__is_referenceable_v<_Tp>, "some nice message");
But in practice, the signature of forward_like itself means that a non-referenceable type is always going to result in forward_like SFINAE-ing away. So I don't see a way to improve the situation and even adding a static_assert to the body of the function wouldn't help, since we'd never reach it.
In light of that, this patch LGTM.
The existing using _ForwardLike declaration already fails with a subsitution failure. The LWG issue was filed to clarify what should happen for non-referencable types.
Added test to verify libc++ is already enforcing the new Mandates.
Implements:
Closes: #105026