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`.
Rather than replacing the code completion file
on the `CompilerInstance` whenever we do a cached
top-level completion, let's set a new main module
instead.
This allows us to properly update the
`LoadedModules` map, and allows the retrieval of
the code completion file to be turned into a
request.
Remove the `PrimarySourceFiles` vector from the
frontend and replace it with a request on
ModuleDecl that retrieves the primary files for
the main module.
This is in preparation for having
`CompilerInstance::getMainModule` automatically
populate the main module with files when queried.
Rather than trying to continue the compilation
with an empty main module, let's bail out early if
we expect an implicit stdlib import and fail to
load in the stdlib.
Rather than adding a ModuleFile to a parent module
and then removing it afterwards if it fails to
load, let's wait until we've loaded the file before
deciding to add it to the parent module. This then
allows us to get rid of `ModuleDecl::removeFile`.
In addition, push down the calls to `addFile` into
the callers of `loadAST` in preparation for
`addFile` being replaced with a one-time-only call
to a `setFiles` method.
We actually wanted to use forEachFileToTypeCheck, which will restrict
the source files we analyze to just the given primaries in incremental
mode, and the whole module's source files otherwise.
While refactoring in 48805b1, I accidentally added the computation of this bit before CompilerInstance::setupInputs is called. This means that the compiler currently does not have any knowledge of any primary input buffers, and thus the check for whole module mode is trivially true. As a consequence, this bit has been true ever since.
Since we seem to have got on just fine without computing this correctly, just inline that truthiness everywhere.
Whoops
This diagnostic logic is currently called from
`finishTypeChecking`, however it doesn't need to
be delayed until after all the source files have
been type-checked, only after they have all had
their imports resolved.
It can therefore be lifted into a request that
operates on a ModuleDecl, and be called from
TypeCheckSourceFileRequest. Being a request will
ensure that the pass is only run once across the
module.
Eventually we'll probably want to re-do import
resolution so that it operates on an entire
module. At that point, we'll want to look at
integrating this diagnostic logic into it.
Rather than eagerly parsing an input .sil file
in `performSemaUpTo`, trigger it from
`performSILGeneration`. This will allow us to
remove the SILModule stored on the
CompilerInstance and will eventually allow the
various SIL tools to just call into
`performSILGeneration` without needing to call
`performSema`.
There's no need to walk all imports of all source files, and bind the
extensions defined therein. The only time that a non-main module
contains source files is when using -enable-source-import, and we
can just explicitly call bindExtensions() in the right place.
Move the playground and debugger transforms out
of the Frontend and into `performTypeChecking`, as
we'd want them to be applied if
`performTypeChecking` was called lazily.
Now that we no longer perform whole-file type
checking for code completion, the ASTVerifier is
no longer expecting fully semantically valid AST.
As such, we no longer need to emit an error to
force it to be more lax with its checks.
Don't create a separate pass manager for those passes, just let them run at the beginning of the performance pipeline.
Regarding generated code this is a NFC.
This change fixes a problem with pass-bisecting (for debugging). Having two instances of the pass manager can cause troubles with bisecting, because -sil-opt-pass-count affects both pass managers at the same time.
