Using the file system path to identify the SDK platform, and determine
which platforms the SDK supports, is unreliable. In particular, the
SDK's file name prefix is usually significant, and dropping it usually
gives incorrect results. Instead, use information from SDKinfo to
positively identify its platform/environment, and to identify which
triples are compatible.
The SDK's SupportedTarget for its CanonicalName doesn't necessarily have
an LLVMTargetTripleSys/LLVMTargetTripleEnvironment that matches the
CanonicalName. e.g. sometimes new SDKs use arm64-apple-ios1.0 during
bringup, but their CanonicalName is set to the new platform. Go back to
using CanonicalName to identify the SDK as a Triple::OSType, and expose
the Triple::EnvironmentType used to build the SDKPlatformInfo when
SupportedTargets isn't present.
Fatal error is more appropriate than unreachable when the SDKSettings is
not in a recognized form (encountered in a few tests with incomplete
SDKSettings.json).
The search path prefix is really a property of the SDK, and not the
target triple. The target is just being used as a proxy for the SDK.
That's problematic when the SDK being used doesn't match the target
assumption, and the prefix should be taken from the SDK rather than hard
coded.
Parse the SupportedTargets, which is what holds the platform prefix, in
DarwinSDKInfo. SupportedTargets contains an entry for the SDK's
canonical name, and that entry holds a valid OS value so use that
instead of the hard coded map. Include the environment which is also
relevant in some situations, and the vendor and object format in case
they're useful later. Skip architectures because they typically aren't
used for doing platform matching.
Whether the SDK supports builtin modules is a property of the SDK
itself, and really has nothing to do with the target. This was already
worked around for Mac Catalyst, but there are some other more esoteric
non-obvious target-to-sdk mappings that aren't handled. Have the SDK
parse its OS out of CanonicalName and use that instead of the target to
determine if builtin modules are supported.
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This change makes it possible to extract iOS-to-another-platform version mappings from `VersionMap` in the `SDKSettings.json` file in Darwin SDKs, for example, `iOS_watchOS` and `iOS_tvOS`.
This code was originally authored by Alex Lorenz.
rdar://81491680
Differential Revision: https://reviews.llvm.org/D116615
This commit adds driver support for the Mac Catalyst target,
as supported by the Apple clang compile
Differential Revision: https://reviews.llvm.org/D105960
This commit adds supports for clang to remap macOS availability attributes that have introduced,
deprecated or obsoleted versions to appropriate Mac Catalyst availability attributes. This
mapping is done using the version mapping provided in the macOS SDK, in the SDKSettings.json file.
The mappings in the SDKSettings json file will also be used in the clang driver for the driver
Mac Catalyst patch, and they could also be used in the future for other platforms as well.
Differential Revision: https://reviews.llvm.org/D105257
