ABI checker imports Swift frameworks by using Swift interfaces for various
reasons. The existing way of controlling preferred importing mechanism is by
setting an environment variable (SWIFT_FORCE_MODULE_LOADING), which may lead
to performance issues because the stdlib could also be loaded in this way.
This patch adds a new front-end option to specify module names for
which we prefer to importing via Swift interface. The option currently is only
accessible via swift-api-digester.
rdar://54559888
This mode is supposed to get all its configuration information from
the switftinterface being read in, but that means that the ASTContext
and ClangImporter that get created by default may not be a sensible
configuration (for example, a mismatched target and SDK, which Clang
emits a warning about). Avoid this by just not creating the ASTContext
if it's already been determined that the frontend is building a module
from a parseable interface.
Previously, we wouldn't pass this flag to sub-invocations, which means
that if we had to fall back and recompile a transitive import, we
wouldn't get a remark.
rdar://50729662
Keep track of information that led the module interface loader to reject loading a compiled module, if it needed to fall back to compiling an interface.
rdar://47792754
This patch modifies ParseableInterfaceBuilder::CollectDepsForSerialization to
avoid serializing dependencies from the runtime resource path into the
swiftmodules generated from .swiftinterface files. This means the module cache
should now be relocatable across machines.
It also modifies ParseableInterfaceModuleLoader to never add any dependencies
from the module cache and prebuilt cache to the dependency tracker (in addition
to the existing behaviour of not serializing them in the generated
swiftmodules). As a result, CollectDepsForSerialization no longer checks if the
dependencies it is given come from the cache as they are provided by the
dependency tracker. It now asserts that's the case instead.
Updates the subinvocation that builds the parseable interface to respect the
-track-system-dependencies flag of the top-level invocation if present, by
including system dependencies in the produced .swiftmodule.
A ‘forwarding module’ is a YAML file that’s meant to stand in for a .swiftmodule file and provide an up-to-date description of its dependencies, always using modification times.
When a ‘prebuilt module’ is first loaded, we verify that it’s up-to-date by hashing all of its dependencies. Since this is orders of magnitude slower than reading mtimes, we’ll install a `forwarding module` containing the mtimes of the now-validated dependencies.
