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
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
We want SILGen and IRGen to also be able to trigger delayed parsing if
necessary, so tweak things here a bit. For now this is NFC, since name
lookup triggers delayed parsing of all types and extensions the first
time a name lookup is performed -- but that is about to change.
There are still cases (a module with a type that's the same name as the
module) where we cannot fully qualify all types. In those cases, allow
them to remain unqualified with a flag, `-Xfrontend
-preserve-types-as-written-in-module-interface`.
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.
swift-tools-version as used by SwiftPM is an actual, parsed field with
semantic meaning. swift-compiler-version as used when generating
module interfaces is just to record what version of the compiler
generated the interface. They shouldn't have the same name.
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
form SerializedModuleLoader into its own ModuleLoader class. (NFC-ish)
This gives better control over the order in which the various module
load mechanisms are applied.
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
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.
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
...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
Replaces SearchPathOptions::RuntimeLibraryImportPath with an equivalent std::vector of paths. Also reimplements SearchPathOptions::SkipRuntimeLibraryImportPaths to cause the list of runtime library import paths to be empty, rather than exiting early from SerializedModuleLoader::findModule().
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.
If the frontend is invoked with
-build-module-from-parseable-interface, we might be trying to persist
and distribute the swiftmodule that gets built. In that case, any
dependencies we list might not be relevant.
This probably isn't really the final answer here; what we want is some
way to say /which/ dependencies are relevant, and how they're related
to how the swiftmodule that gets used. Most likely the right answer
here is to limit this to dependencies within the SDK or something.
Otherwise, the top-level compilation gets the benefit of the prebuilt
cache path, but the sub-invocations for swiftinterfaces that /do/
need to be compiled do not.
