Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
This test is pretty brittle on such a short file. If a member of the
timer output is zero, that member is omitted from the output. With how
short the file is, various fields come back zero occasionally.
On the Linux CI bot, there was a run with no "System Time", while I was
seeing it failing locally due to other missing time fields.
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.
This Driver/lock_interface.swift test has been
spontaenously failing for the past few days.
I've decided to disable it until an investigation
and fix can happen.
rdar://82261445
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
To allow us to start testing language changes tied to a future Swift 6 mode without actually *shipping* a Swift 6 mode to customers who might accidentally use it before it's ready.
This commit also adds parallel tests for a number of already existing (but untested) Swift 6 mode behaviors.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
SourceKit invokes the legacy driver. Providing this flag in the IDE
means the command lines SourceKit forms to run semantic requests in the
editor are all invalid.
Teach the legacy driver to eat this flag.
rdar://80811565
This commit adds support for the -lto_library flag, allowing users to specify a custom LTO library on Darwin. This also fixes an issue where the default LTO library is used even if Driver is run from inside an alternate toolchain.
Gather 'round to hear tell of the saga of autolinking in incremental
mode.
In the beginning, there was Swift code, and there was Objective-C code.
To make one import bind two languages, a twinned Swift module named the same as an
Objective-C module could be imported as an overlay. But all was not
well, for an overlay could be created which had no Swift content, yet
required Swift symbols. And there was much wailing and gnashing of teeth
as loaders everywhere disregarded loading these content-less Swift
libraries.
So, a solution was found - a magical symbol _swift_FORCE_LOAD_$_<MODULE>
that forced the loaders to heed the dependency on a Swift library
regardless of its content. It was a constant with common linkage, and it
was good. But, along came COFF which needed to support autolinking but
had no support for such matters. It did, however, have support for
COMDAT sections into which we placed the symbol. Immediately, a darkness
fell across the land as the windows linker loudly proclaimed it had
discovered a contradiction: "_swift_FORCE_LOAD_$_<MODULE> cannot be
a constant!", it said, gratingly, "for this value requires rebasing."
Undeterred, we switched to a function instead, and the windows linker
happily added a level of indirection to its symbol resolution procedure
and all was right with the world.
But this definition was not all right. In order to support multiple
translation units emitting it, and to prevent the linker from dead
stripping it, Weak ODR linkage was used. Weak ODR linkage has the nasty
side effect of pessimizing load times since the dynamic linker must
assume that loading a later library could produce a more definitive
definition for the symbol.
A compromise was drawn up: To keep load times low, external linkage was
used. To keep the linker from complaining about multiple strong
definitions for the same symbol, the first translation unit in the
module was nominated to recieve the magic symbol. But one final problem
remained:
Incremental builds allow for files to be added or removed during the
build procedure. The placement of the symbol was therefore dependent
entirely upon the order of files passed at the command line. This was no
good, so a decree was set forth that using -autolink-force-load and
-incremental together was a criminal offense.
So we must compromise once more: Return to a symbol with common linkage,
but only on Mach-O targets. Preserve the existing COMDAT-friendly
approach everywhere else.
This concludes our tale.
rdar://77803299
Rather than computing an absolute path relative to Swift's resource
directory, use the compiler driver to locate the profiling runtime
relative to the C/C++ compiler's resource directory. This ensures that
we correctly locate the runtime. Additionally, because clang adds the
clang resource directory to the library search path, we do not need to
compute the path and can rely on the linker locating the runtime via the
library search path. This simplifies the handling for the profile
runtime linking on Windows.
Out of abundant paranoia, place the library link request after the
forced symbol inclusion as a GC root to ensure that `/opt:ref` will not
accidentally dead strip the symbol and force a reload of the library.
The Windows linker does not support `-u`. Furthermore, the compiler
driver does not forward the `-u` option to the linker. We correctly use
the `/include:` option from the linker. This should ensure that the
symbol is preserved even with `/opt:ref`. This spelling should be
compatible with both lld and link, which should provide sufficient
portability.
Take the opportunity to make it more obvious that the two parameters are
creating a pair that will be concatenated by using a braced initializer.
See
https://docs.microsoft.com/en-us/cpp/build/reference/include-force-symbol-references?view=msvc-160
for more details on the option.
When building a static library with debug information, do not create a
dSYM generation job as it cannot be executed on a non-image target.
This is important for the case where the single invocation is both the
compile and link job.
This was detected in conjunction with @gottesmm.
