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.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
When loading a module supporting multiple targets, the module loader now looks for a file named with a normalized version of the target triple first, and only falls back to the architecture name if the normalized triple is not found.
LLVM r340675 added a new HermitCore OS type to triples, which broke the
Swift build because it is using -Werror,-Wswitch and the new value was not
handled in swift::getPlatformNameForTriple
