[libcxx-commits] [libcxx] [libc++] P2641R4: Checking if a `union` alternative is active (`std::is_within_lifetime`) (PR #107450)

Mital Ashok via libcxx-commits libcxx-commits at lists.llvm.org
Wed Sep 11 03:44:49 PDT 2024


================
@@ -0,0 +1,32 @@
+//===----------------------------------------------------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03
+
+// <type_traits>
+
+// LWG4138 <https://cplusplus.github.io/LWG/issue4138>
+// std::is_within_lifetime shouldn't work when a function type is
+// explicitly specified, even if it isn't evaluated
+
+#include <type_traits>
+#include <cassert>
+
+#include "test_macros.h"
+
+void fn();
+
+int main(int, char**) {
+#ifdef __cpp_lib_is_within_lifetime
+  constexpr bool _ = true ? false : std::is_within_lifetime<void()>(&fn);
----------------
MitalAshok wrote:

For LWG4138. Current standard wording is that something like this should be fine as the `std::is_within_lifetime` with the function pointer isn't evaluated (Just like how `true ? constant-expression : throw` is fine), but the library issue aims to make it ill-formed.  
Clang's current `__builtin_is_within_lifetime` implementation errors out if it is instantiated with a function pointer typed object. But I've made the libc++ implementation give a nicer error that doesn't point to the builtin (<https://godbolt.org/z/1G1sf51a1>) and this is the test for that.


https://github.com/llvm/llvm-project/pull/107450


More information about the libcxx-commits mailing list