It is now the responsibility of the scanDependencies code to instantiate (and share) the cache.
e.g. FrontendTool instantiates a new cache per `-scan-dependencies` invocation, and the DependencyScanningTool keeps one shared cache across its lifetime.
Also, continue trying opening files even if any of primary files are
missing so that the caller can know all files failed to open.
rdar://problem/33757793
This will allow individual module scans in batch-scanning mode to share the already-scanned Swift and Clang modules, and avoid instantiating a brand new Clang `DependencyScanningService` for each batch entry.
Performance-improvement anecdote:
A simple experiment which performs a batch scan of all modules involved in planning a build of SwiftPM (using SwiftPM in explicit module build mode), which includes 126 batch entries (scan entry-points), with 21 distinct Swift modules and 27 distinct Clang modules (many Clang modules are scanned multiple times, at different target versions), this modification reduces the total time taken from ~34 seconds to ~6.
Adds a new frontend option
"-experimental-allow-module-with-compiler-errors". If any compilation
errors occur while generating the .swiftmodule, this mode will skip SIL
entirely and only serialize the (likey invalid) AST.
This existence of this option during generation is serialized into the
resulting .swiftmodule. Errors found in deserialization are only allowed
if it is set.
Primarily intended for IDE requests (eg. indexing and code completion)
to ensure robust cross-module results, despite possible errors.
Resolves rdar://69815975
Adds a new flag "-experimental-skip-all-function-bodies" that skips
typechecking and SIL generation for all function bodies (where
possible).
`didSet` functions are still typechecked and have SIL generated as their
body is checked for the `oldValue` parameter, but are not serialized.
Parsing will generally be skipped as well, but this isn't necessarily
the case since other flags (eg. "-verify-syntax-tree") may force delayed
parsing off.
This refactoring allows us to drop ModuleInterfaceLoader when explicit modules
are enabled. Before this change, the dependencies scanner needs the loader to be
present to access functionalities like collecting prebuilt module candidates.
These inputs were previously modeled as Swift files, which would lead to bizarre situations where parts of the pipeline expecting Swift inputs actually wound up parsing Objective-C.
We need ClangImporterOptions to be persistent for several scenarios: (1)
when creating a sub-ASTContext to build Swift modules from interfaces; and
(2) when creating a new Clang instance to invoke Clang dependencies scanner.
This change is NFC.
Try to impose a simple structure that splits performing actions from the
pre and post-pipeline conditions. Wherever actions would take more than
a simple return, split them into functions. Refine functions that
perform effects to return status codes when they fail. Finally,
delineate functions that need semantic analysis from those that do not.
Overall this should be NFC.
In order to avoid accidentally implicitly loading modules that are expected but were not provided as explicit inputs.
- Use either SerializedModuleLoader or ExplicitSwiftModuleLoader for loading of partial modules, depending on whether we are in Explicit Module Build or Implicit Module Build mode.
Previously we would only link `.sib` partial
modules in SILGen, with other kinds of serialized
ASTs being linked just before the SILOptimizer if
`-sil-merge-partial-modules` was specified.
However linking them always seems to be the desired
behaviour, so adjust SILGen to link SIL for all
serialized AST inputs.
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`.
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.
There's no reason clients need to be able to access this data directly.
It obscures where module loading is actually happening, and makes it too
easy to accidentally register a module with the wrong identifier in the
context.
Hide the registration operations behind opaque accessors.
We were not using the primary benefits of an intrusive list, namely the
ability to insert or remove from the middle of the list, so let's switch
to a plain vector. This also avoids linked-list pointer chasing.
Now that it no longer needs to handle the
parse-only case, we can simplify things by having
`performSema` call into
`performParseAndResolveImportsOnly`.
Most clients were only using it to populate the
main module with files, which is now done by
`getMainModule`. Instead, they can now just rely
on parsing happening lazily.
Move into `performEndOfPipelineActions`, and move
the call up a bit in `performCompile` to make sure
it gets called even for a parse-only invocation.
Unfortunately this requires carving out an
exception for `-emit-imported-modules`, which can
load modules.
Rather than waiting until one of the performXXX
methods are called, make sure all the main module's
files have been populated up-front by
`getMainModule`.
Lift the `DisablePoundIfEvaluation` parsing option
into `LangOptions` to subsume the need for the
`EvaluateConditionals` parameter, and sink the
computation of `CanDelayBodies` down into
`createSourceFileForMainModule`.
To support -disable-implicit-swift-modules, the explicitly built modules
are passed down as compiler arguments. We need this new module loader to
handle these modules.
This patch also stops ModuleInterfaceLoader from building module from interface
when -disable-implicit-swift-modules is set.
Sink the `BuildSyntaxTree` and
`CollectParsedTokens` bits into
`SourceFile::ParsingFlags`, with a static method
to get the parsing options from the lang opts.
Also add a parsing flag for enabling the interface
hash, which can be used instead of calling
`enableInterfaceHash`.
