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
This is a follow up to the discussion on #22740 to switch the host
libraries to use the `target_link_libraries` rather than the
`LINK_LIBRARIES` special handling. This allows the dependency to be
properly tracked by CMake and allows us to use the more modern syntax.
Windows doesn't know what a shebang is, so it's unable to run tests that
use -driver-use-frontend-path with a script. This allows the script
interpreter to be run as the executable with the script as its first
argument. e.g. --driver-use-frontend-path "python;my-script.py"
This patch allows `-serialize-diagnostics-path` for the interpret mode.
There is one file compiled in such mode, so it makes sense to support
this flag to specify an explicit output path for diagnostics emission.
Resolves: SR-9670
Including the mangled names in anonymous context metadata can bloat
code size, and is not needed for normal runtime resolution. However,
it aids debugging, so have -g implies the emission of this extra
metadata, which is always optional.
Kelly Hutchison
Joe Groff
Joe Groff
Saleem Abdulrasool
Jordan Rose
Alex Langford
Tony Allevato
Harlan Haskins
Michael Gottesman
Julian Lettner
Jason Mittertreiner
Julian Lettner
Slava Pestov
David Ungar
Ding Ye
Doug Gregor
Ankit Aggarwal