In the fast dependency scanner, depending on whether a module intrface was found via the import search path or framework search path, encode into the dependency graph Swift module details, whether a given module is a framework.
Some implicitly imported modules aren't printed in the textual interface file as explicit import,
e.g. SwiftOnoneSupport. We should check implicit imports and add them to the dependency graph.
Since -emit-module-from-interface now emits forwarding modules, explicit module
loader should be able to accept forwarding modules and unbox their actual binary
contents.
-compile-module-from-interface action now takes arguments of -candidate-module-file.
If one of the candidate module files is up-to-date, the action emits a forwarding
module pointing to the candidate module instead of building a binary module.
Instead of replacing an interface file with its up-to-date compile module,
the dep-scanner should report potentially up-to-date module candidates either adjacent to
the interface file or in the prebuilt module cache. swift-driver should later pass down
these candidates to -compile-module-from-interface invocation and the front-end job
will check if one of the candidates is ready to use. The front-end job then either emits a forwarding
module to an up-to-date candidate or a binary module.
For the explicit module mode, swift-driver uses -compile-module-from-interface to
generate modules from interfaces found by the dependency scanner. However, we don't
need to build the binary module if up-to-date modules are available, either adjacent
to the interface file or in the prebuilt module cache directory. This patch teaches
dependencies scanner to report these ready-to-use binary modules.
Expand the FrontendOptions to allow the enabling
of the dependency tracker for non-system
dependencies, and switch the previous clients of
`createDependencyTracker` over to using this
option. This ensures that the dependency tracker
is now set only during `CompilerInstance::setup`.
We will eventually move the protocol entirely to using a JSON file for
explicit Swift modules. Before we finish migrating, we should be forgiving
about using the legacy -swift-module-file argument.
Instead of taking paths of Swift module files from front-end command line
arguments, we should take a JSON file specifying details of explicit modules.
The advantages is (1) .swiftdoc and .swiftsourceinfo can be associated
with a .swiftmodule file, and (2) module names are explicitly used as
keys in the JSON input so we don't need to eagerly deserialize a .swiftmodule
file to collect the module name.
Fix the search order for module interfaces to respect the documented
behavior:
1. Local cache
2. Next to the .swiftinterface
3. Prebuilt cache
Fixing the order of the last two allows the XcodeDefault compiler to
prioritize swiftmodule files with SPI information.
rdar://problem/64097455
Building in incremental mode incurs the overhead associated with the
incremental dependency tracking infrastructure. Considering we're
throwing away all of this stuff anyways, let's just build in WMO to
avoid that.
Swift interface files may specify the effective language version to use. When building
a PCM loadable for these textual interface files, we should respect the language
version. This patch moves -fapinotes-swift-version from the generic PCM
commands to the extra PCM arguments owned by each loading Swift module.
Building each Swift module explicitly requires dependency PCMs to be built
with the exactly same deployment target version. This means we may need to
build a Clang module multiple times with different target triples.
This patch removes the -target arguments from the reported PCM build
arguments and inserts extraPcmArgs fields to each Swift module.
swift-driver can combine the generic PCM arguments with these extra arguments
to get the command suitable for building a PCM specifically for
that loading Swift module.
