Make sure that we add the appropriate rpaths so that the appropriate
_Concurrency back-deployment library can be picked up.
We don't need to update the Swift driver since it uses the C++ driver
as the source of truth to determine if the relevant rpath should be
added or not.
The triple name aarch64_32 does not actually name a valid platform. The
actual platform (and valid triple arch string, confusingly enough) is
arm64_32. Remap between the two to correct for this difference.
rdar://77281393
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
Prebuilt-module directory now contains a SystemVersion.plist file copied from the SDK
it's built from. This patch teaches the compiler to remark this version and the SDK version
when -Rmodule-interface-rebuild is specified. The difference between these versions could
help us debug unusable prebuilt modules.
Some code paths that see target triples go through the frontend
without seeing the driver. Therefore, perform the same "simulator"
inference for x86 iOS/tvOS/watchOS triples also in the frontend,
to ensure that we remain compatible. Also make sure that
-print-target-info performs the appropriate adjustment.
The *-simulator target triples have been used consistently in tools for
several years to indicate simulator targets. Stop inferring the
simulator part, rdar://problem/35810403.
Some code paths that see target triples go through the frontend
without seeing the driver. Therefore, perform the same "simulator"
inference for x86 iOS/tvOS/watchOS triples also in the frontend,
to ensure that we remain compatible. Also make sure that
-print-target-info performs the appropriate adjustment.
The *-simulator target triples have been used consistently in tools for
several years to indicate simulator targets. Stop inferring the
simulator part, rdar://problem/35810403.
Add the platform conditional and set up other basics for the toolchain.
The ConditionalCompilation tests are updated to match, since otherwise
they seem to trip when building on non-OpenBSD platforms. The
Driver/linker test is updated to ensure lld is passed on this platform.
Note that OpenBSD calls "x86_64" as "amd64", so we use that name for the
architecture instead of trying to alias one to the other, as this makes
things simpler.
Add support in the driver and frontend for macCatalyst target
targets and library search paths.
The compiler now adds two library search paths for overlays when compiling
for macCatalyst: one for macCatalyst libraries and one for zippered macOS
libraries. The macCatalyst path must take priority over the normal macOS path
so that in the case of 'unzippered twins' the macCatalyst library is
found instead of the macOS library.
To support 'zippered' builds, also add support for a new -target-variant
flag. For zippered libraries, the driver invocation takes both a -target and a
-target-variant flag passes them along to the frontend. We support builds both
when the target is a macOS triple and the target variant is macCatalyst and
also the 'reverse zippered' configuration where the target is macCatalyst and the
target-variant is macOS.
The android API level can be ignored when loading the module. The API
level controls the NDK APIs which are available and is equivalent to the
SDK version for Darwin. This allows us to keep the API level in the
triple which future versions of Android's toolchain does.
The backwards-deployment install name trickery we're using doesn't
handle "patch" components in version numbers, so we still need to
provide an rpath even when deploying to macOS 10.14.4.
