[libcxx-commits] [libcxx] [libc++] Remove _LIBCPP_DISABLE_AVAILABILITY macro (PR #112952)

[via libcxx-commits]

================
@@ -85,6 +85,9 @@ Deprecations and Removals
 - The function ``__libcpp_verbose_abort()`` is now ``noexcept``, to match ``std::terminate()``. (The combination of
   ``noexcept`` and ``[[noreturn]]`` has special significance for function effects analysis.)
 
+- 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.
----------------
h-vetinari wrote:

So to answer the questions w.r.t. our setup (to the best of my understanding, much of the setup was done before my time, I'm trying to document & improve things as I go).

Because our users are necessarily installing a full environment (where we control dependencies and distribution), we can rely on the fact that we can always ship an up-to-date `libc++.dylib`. We also use up-to-date the libc++ headers when compiling things, but we still need to use point to _some_ Apple SDK (for which older versions are available, e.g. from https://github.com/phracker/MacOSX-SDKs or https://github.com/alexey-lysiuk/macos-sdk), and we're generally on a 10.13 baseline for now.

We need the SDK for platform-related things and the C stdlib, so this is kind of unavoidable. However, the libc++ headers will trigger availability warnings based on the detected macOS version and therefore report false positives (from our POV, because our C++ stdlib is always up-to-date and available).

These things happen at runtime (from the POV of libc++), because different packages may require a newer SDK for some reason, and we can provide that based on the configuration of a given build (often while still leaving `MACOSX_DEPLOYMENT_TARGET` unchanged).

We're also relying on ABI stability of libc++, in the sense that artefacts compiled against libc++ vN get a runtime dependency `libcxx >=N`, so we that if we later have `libc++.{N+2}.dylib` in the environment, things still work in the vast majority of situations. I don't want to scare people here in that this is what the ironclad expectation is, but rather that this is something that has worked for us for years, and rebuilding literally 10's of thousands of artefacts for every new libc++ version is simply not realistic.

So if `_LIBCPP_DISABLE_AVAILABILITY` gets removed, AFAIU we'd have to either:
* Patch things so that we recreated the effect of `_LIBCPP_DISABLE_AVAILABILITY`
* Provide our own vendor availability annotations that match that effect

Neither sounds impossible, but we try to minimize the amount of [patches](https://github.com/conda-forge/libcxx-feedstock/tree/main/recipe/patches) we carry, obviously...

Actually there is one exception where we do modify the default availability annotations, which has to do with another wrinkle. While we could build and ship `libc++abi` just fine (and we did in the past), there are situations where certain libraries or frameworks (including CPython) will bypass the fact that everything points to our custom `$PREFIX` and simply go to the system `libc++abi` straight away. Because it's basically impossible to chase down and patch all cases where this happens, we've stopped shipping `libc++abi` and now always rely on the system-provided one, which is why we unconditionally disable `_LIBCPP_AVAILABILITY_HAS_INIT_PRIMARY_EXCEPTION` for example, as the required `___cxa_init_primary_exception` isn't available before macOS 15 AFAIU (and our deployment target baseline is much lower). This is also why I'm interested in `-DLIBCXX_CXX_ABI=system-libcxxabi`, c.f. https://github.com/llvm/llvm-project/pull/110920.

Finally, where we're aware of it, we do patch relevant ABI differences for older macOS system libs, compare e.g. [this patch](https://github.com/conda-forge/libcxx-feedstock/blob/main/recipe/patches/0001-Fix-ABI-compatibility-with-system.patch) to realign a struct, resp. the related [discussion](https://discourse.llvm.org/t/shipping-custom-libc-on-macos/58606) (I think the original email [thread](https://lists.llvm.org/pipermail/libcxx-dev/2021-July/001172.html) got split a bit by the discourse migration). This isn't great, but given that the system ABI isn't 100% stable, this is +/- the best we can do under the given constraints.

Hope that explains the situation a bit more. Happy to answer more questions of course, and thanks for giving us a chance to make the case!



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