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`.
This makes it easier to specify OptionSet arguments.
Also modify appropriate uses of ModuleDecl::ImportFilter to take
advantage of the new constructor.
The use of `SWIFT_DEFER` previously meant that we
may return `false` from `performCompile` even if
an error was produced from
`performEndOfPipelineActions`.
To remedy this, introduce a lambda that both calls
`performEndOfPipelineActions`, and checks to see
if there was an error. Then, enforce that all exit
paths call this lambda.
Move both the loaded module trace output and
"additional whole module outputs" to the end of
the pipeline, ensuring to preserve the behaviour
where we skip them if we encountered an error.
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.
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.
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.
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.
Lift the `DisablePoundIfEvaluation` parsing option
into `LangOptions` to subsume the need for the
`EvaluateConditionals` parameter, and sink the
computation of `CanDelayBodies` down into
`createSourceFileForMainModule`.
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.
When resolving direct dependencies for a given Swift module, we go over all Clang module dependencies and add, as additional dependencies, their Swift overlays. We find overlays by querying `ASTContext::getModuleDependencies` with the Clang module's name. If the Clang module in question is a dependency of a Swift module with the same name, we will end up adding the Swift module as its own dependence.
e.g.
- Swift A depends on Clang A
- Add Clang A to dependencies of Swift A
- We look for overlays of Clang A, by name, and find Swift A
- Add Swift A to dependencies of Swift A
From what I can tell, the logic upstream is sound, and `getModuleDependencies` is doing the right thing, so this change is simply restricting what gets added when we are looking for overlays.
Resolves rdar://problem/63731428
The reasons for disabling it appear to now be
outdated. Re-enable it, and run it after the
entire pipeline has finished to make sure we
verify any decls deserialised during SIL/IRGen.
