Xcode 13's clang has them. For the included testcase, Xcode's clang
behaves like the implementation in this patch.
Availability.h in the macOS 12.0 SDK (part of Xcode 13, and the current
stable version of the macOS SDK) does something like:
#if defined(__has_builtin) ... #if __has_builtin(__is_target_os) #if __has_builtin(__is_target_environment) #if __has_builtin(__is_target_variant_os) #if __has_builtin(__is_target_variant_environment) #if (... && ((__is_target_os(ios) && __is_target_environment(macabi)) || (__is_target_variant_os(ios) && __is_target_variant_environment(macabi)))) #define __OSX_AVAILABLE_STARTING(_osx, _ios) ... #define __OSX_AVAILABLE_BUT_DEPRECATED(_osxIntro, _osxDep, _iosIntro, _iosDep) ... #define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(_osxIntro, _osxDep, _iosIntro, _iosDep, _msg) ...
So if has_builtin(is_target_variant_os) or
has_builtin(is_target_variant_environment) are false, these defines are not
defined.
Most of the time, this doesn't matter. But open-source clang currently fails
to commpile a file containing only #include <Security/cssmtype.h> when
building for catalyst by adding a -target arm64-apple-ios13.1-macabi triple,
due to those __OSX_AVAILABLE macros not being set correctly.
If a potential future SDK version were to include cssmtype.h transitively
from a common header such as <Foundation/Foundation.h>, then it would become
close to impossible to build Catalyst binaries with open-source clang.
To fix this for normal catalyst builds, it's only necessary that
__has_builtin() evaluates to true for these two built-ins -- the implementation
of them doesn't matter. But as a courtesy, a correct (at least on the test
cases I tried) implementation is provided. (This should also help people who
try to build zippered code, where having the correct implementation does
matter.)
(I saw this comment, but system headers force our hand.)