[clang] Add __is_target_variant_{os,environment} builtins
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.) Differential Revision: https://reviews.llvm.org/D132754
Loading
Please sign in to comment