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.
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
Windows requires a handle to get memory usage, so do a slight refactor
to collect the child's memory usage as it exits instead of as the parent
is cleaning up.
Previously, the TSan runtime only required libdispatch on Darwin, which
required no explicit linker flags, because libdispatch is always
provided by the system (libSystem).
Now, the TSan runtime also has a link-time dependency on libdispatch on
Linux, where libdispatch (and the blocks runtime) is just another
library. We therefore need to specify them as additonal linker options.
The ModuleWrap job is responsible for wrapping the AST into the swift
module. It was only enabled for ELF objects, but COFF needs this
operation to be performed as well. Enable this for the COFF targets as
well. This is needed to fix the DebugInfo AST Section verification.
...and remove the option. This is ~technically~ CLI-breaking because
Swift 5 shipped this as a hidden driver option, but it wouldn't have
/done/ anything in Swift 5, so I think it's okay to remove.
Note that if a parseable interface (.swiftinterface) and a binary
interface (.swiftmodule) are both present, the binary one will still
be preferred. This just /allows/ parseable interfaces to be used.
rdar://problem/36885834
