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.
If the compiler arguments have errors in them (e.g. because a file with the same name is used twice), we can often still fulfill SourceKit requests because the compiler argument errors are only relevant for later stages of the compilation process.
Instead of bailing out early, do a best effor retrieving the compiler arguments that are valid and ignoring the errors.
Fixes rdar://77618144
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
Introduce flags `-enable-actor-data-race-checks` and
`-disable-actor-data-race-checks` to enable/disable emission of code
that checks that we are on the correct actor. Default to `false` for
now but make it easy to enable in the future.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
Clang deduces its installation directory from the `argv[0]` parameter (see clang/lib/Frontend/CreateInvocationFromCommandLine.cpp), and the default include search paths are computed based on the installation directory.
This change allows compiling Swift code that imports the C++ stdlib without having to manually specify the include search path of `std` headers.
If the driver is only set up to get the frontend invocation (e.g. from sourcekitd), don't validate that we can link against ARCLite because
a) we don't care about link-time when we are only interested in the frontend invocation
b) finding arclite might cause us to find clang using xcrun which in turn can cause sourcekitd to hang.
rdar://50659268
Introduce a new compiler flag `-module-abi-name <name>` that uses the
given name as the ABI name for the module (rather than the module's
name in source code). The ABI name impacts name mangling and metadata.
The frontend supports this via new options -index-unit-output-path and
-index-unit-output-path-filelist that mirror -o and -output-filelist. These are
intended to allow sharing index data across builds in separate directories (so
different -o values) that are otherwise equivalent as far as the index data is
concerned (e.g. an ASAN build and a non-ASAN build) by supplying the same
-index-unit-output-path for both.
This change updates the driver to add these new options to the frontend
invocation 1) when a new "index-unit-output-path" entry is specified for one
or more input files in the -output-file-map json or 2) if -index-file is
specified, when a new -index-unit-output-path driver option is passed.
Resolves rdar://problem/74816412
To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
In the legacy driver, these flags will merely be propagated to the
frontends to indicate that they should disable serialization of
incremental information in swift module files.
In the new driver, these flags control whether the Swift driver performs
an incremental build that is aware of metadata embedded in the module.
Kudos to David for coming up with our new marketing name: Incremental
Imports.
rdar://74363450
Add a new swift-frontend driver option that extract APIs in the swift
module and print in JSON format. This is to allow tooling to understand
and process swift APIs without the need to be a swift compiler or
understand swift module/AST.
Unlike the frontend, the driver doesn't account for any VFS overlays set up
by the -vfsoverlay option when processing its input files. It also errors
if any of those input files don't exist on the file system. This makes it
impossible to use a file that only exists in the VFS as input to the driver,
even though the same file would be handled without issue by the frontend.
If the file doesn't exist even accounting for the VFS the frontend emits
a missing file diagnostic, so this change just suppresses the existence
check for inputs when a -vfsoverlay option is present.
Resolves rdar://problem/72485443
We've seen bad file descriptor errors in certain build environments (rdar://73157185) and retrying
opening those files seems to be a walkaround. In this change, we allow the
compiler to retry expanding reponse files in argument lists.
rdar://73892564
Remove this distinction without a difference. Originally, the thought
was to
1) Isolate the cross-module build infrastructure
2) Provide a signal to the driver that a dependency had swiftdeps info
in it
But the driver need only notice swiftmodule files as external
dependencies and try to extract that information if it can to divine the
signal it needs. Additionally, we can give it fingerprints as priors to
let it know there might be incremental info to be had.
