Add a new action, LoadModuleJobAction, that the driver can use to schedule a
load of a given module before we fan out and invoke the frontend multiple
times. This gives the module interface loader a chance to compile it from a
module interface before we start with parallel invocations, avoiding starting
potentially dozens of redundant compiles of a large module. Start by using this
on the standard library.
Quick fix for rdar://52839445
Rather than aborting due to an assertion failure, emit a diagnostic.
This is much safer and generally easier to understand why the command
failed. It solves the problem of running swiftc from the build without
the path being set such that the clang++ driver is found by the swift
driver.
This commit also includes cases where user uses -Fsystem and when path
ends in ".framework/"
(cherry picked from commit a5d9750a9d25441517f3bec97488f57d1bb4b03f)
The librarian on Windows is a part of the linker. Enabling `-use-ld=`
for driver for static linking on Windows enables the user to override
the linker. This is particularly important for cross-linking Windows
from Linux where link.exe is not present as it is a part of the MSVC
toolset.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
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
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
