https://github.com/llvmbot created 
https://github.com/llvm/llvm-project/pull/138674

Backport 25fc52e655fb4bfd3bb89948d5cbfe011e1b8984

Requested by: @ldionne

>From be87564873d74080a5a45bb79221690c3fd4b740 Mon Sep 17 00:00:00 2001
From: Louis Dionne <ldionn...@gmail.com>
Date: Mon, 5 May 2025 17:19:13 -0400
Subject: [PATCH] [libc++] Re-introduce _LIBCPP_DISABLE_AVAILABILITY (#134158)

The `_LIBCPP_DISABLE_AVAILABILITY` macro was removed in afae1a5f32bb as an
intended no-op. It turns out that some projects are making use of that
macro to work around a Clang bug with availability annotations that
still exists: https://github.com/llvm/llvm-project/issues/134151.

Since that Clang bug still hasn't been fixed, I feel that we must sill
honor that unfortunate macro until we've figured out how to get rid of
it without breaking code.

(cherry picked from commit 25fc52e655fb4bfd3bb89948d5cbfe011e1b8984)
---
 libcxx/docs/ReleaseNotes/20.rst               |  3 --
 libcxx/include/__configuration/availability.h |  8 ++-
 .../vendor/apple/disable-availability.sh.cpp  | 49 +++++++++++++++++++
 3 files changed, 56 insertions(+), 4 deletions(-)
 create mode 100644 libcxx/test/libcxx/vendor/apple/disable-availability.sh.cpp

diff --git a/libcxx/docs/ReleaseNotes/20.rst b/libcxx/docs/ReleaseNotes/20.rst
index 06e6e673b5508..f81a573845e6f 100644
--- a/libcxx/docs/ReleaseNotes/20.rst
+++ b/libcxx/docs/ReleaseNotes/20.rst
@@ -153,9 +153,6 @@ Deprecations and Removals
   headers as an extension and only deprecates them. The 
``_LIBCPP_DISABLE_DEPRECATION_WARNINGS`` macro can be defined to
   suppress deprecation for these headers.
 
-- The ``_LIBCPP_DISABLE_AVAILABILITY`` macro that was used to force-disable 
availability markup has now been removed.
-  Whether availability markup is used by the library is now solely controlled 
at configuration-time.
-
 - The pointer safety functions ``declare_reachable``, ``declare_no_pointers``, 
``undeclare_no_pointers`` and
   ``__undeclare_reachable`` have been removed from the library. These 
functions were never implemented in a non-trivial
   way, making it very unlikely that any binary depends on them.
diff --git a/libcxx/include/__configuration/availability.h 
b/libcxx/include/__configuration/availability.h
index f9e52a690c05c..aa2e75b6f6fe8 100644
--- a/libcxx/include/__configuration/availability.h
+++ b/libcxx/include/__configuration/availability.h
@@ -69,7 +69,13 @@
 
 // Availability markup is disabled when building the library, or when a 
non-Clang
 // compiler is used because only Clang supports the necessary attributes.
-#if defined(_LIBCPP_BUILDING_LIBRARY) || defined(_LIBCXXABI_BUILDING_LIBRARY) 
|| !defined(_LIBCPP_COMPILER_CLANG_BASED)
+//
+// We also allow users to force-disable availability markup via the 
`_LIBCPP_DISABLE_AVAILABILITY`
+// macro because that is the only way to work around a Clang bug related to 
availability
+// attributes: https://github.com/llvm/llvm-project/issues/134151.
+// Once that bug has been fixed, we should remove the macro.
+#if defined(_LIBCPP_BUILDING_LIBRARY) || defined(_LIBCXXABI_BUILDING_LIBRARY) 
||                                       \
+    !defined(_LIBCPP_COMPILER_CLANG_BASED) || 
defined(_LIBCPP_DISABLE_AVAILABILITY)
 #  undef _LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS
 #  define _LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS 0
 #endif
diff --git a/libcxx/test/libcxx/vendor/apple/disable-availability.sh.cpp 
b/libcxx/test/libcxx/vendor/apple/disable-availability.sh.cpp
new file mode 100644
index 0000000000000..474b3f83c6044
--- /dev/null
+++ b/libcxx/test/libcxx/vendor/apple/disable-availability.sh.cpp
@@ -0,0 +1,49 @@
+//===----------------------------------------------------------------------===//
+//
+// 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: stdlib=apple-libc++
+
+// This test is dependent on the code generated by the compiler, and it doesn't
+// work properly with older AppleClangs.
+// UNSUPPORTED: apple-clang-15
+
+// This test ensures that we retain a way to disable availability markup on 
Apple platforms
+// in order to work around Clang bug 
https://github.com/llvm/llvm-project/issues/134151.
+//
+// Once that bug has been fixed or once we've made changes to libc++'s use of 
availability
+// that render that workaround unnecessary, the macro and this test can be 
removed.
+//
+// The test works by creating a final linked image that refers to a function 
marked with
+// both an availability attribute and with _LIBCPP_HIDE_FROM_ABI. We then 
check that this
+// generates a weak reference to the function -- without the bug, we'd expect 
a strong
+// reference or no reference at all instead.
+
+// First, test the test. Make sure that we do (incorrectly) produce a weak 
definition when we
+// don't define _LIBCPP_DISABLE_AVAILABILITY. Otherwise, something may have 
changed in libc++
+// and this test might not work anymore.
+// RUN: %{cxx} %s %{flags} %{compile_flags} %{link_flags} -fvisibility=hidden 
-fvisibility-inlines-hidden -shared -o %t.1.dylib
+// RUN: nm -m %t.1.dylib | c++filt | grep value > %t.1.symbols
+// RUN: grep weak %t.1.symbols
+
+// Now, make sure that 'weak' goes away when we define 
_LIBCPP_DISABLE_AVAILABILITY.
+// In fact, all references to the function might go away, so we just check 
that we don't emit
+// any weak reference.
+// RUN: %{cxx} %s %{flags} %{compile_flags} %{link_flags} -fvisibility=hidden 
-fvisibility-inlines-hidden -D_LIBCPP_DISABLE_AVAILABILITY -shared -o %t.2.dylib
+// RUN: nm -m %t.2.dylib | c++filt | grep value > %t.2.symbols
+// RUN: not grep weak %t.2.symbols
+
+#include <version>
+
+template <class T>
+struct optional {
+  T val_;
+  _LIBCPP_HIDE_FROM_ABI _LIBCPP_INTRODUCED_IN_LLVM_11_ATTRIBUTE T value() 
const { return val_; }
+};
+
+using PMF = int (optional<int>::*)() const;
+PMF f() { return &optional<int>::value; }

_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to