This matches the behavior of the current client (`swift-driver`) and reduces ambiguity in how the nodes in the graph are to be treated. Swift dependencies with a textual interface, for example, must be built into a binary module by clients. Swift dependencies without a textual interface, with only a binary module, are to be used directly, without any up-to-date checks.
Note, this is distinct from Swift dependencies that have a textual interface, for which we also detect potential pre-build binary module candidates. Those are still reported in the `details` field of textual Swift dependencies as `prebuiltModuleCandidates`.
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
Also perform the plumbing necessary to convince the rest of the compiler that they're just ordinary external dependencies. In particular, we will still emit these depenencies into .d files, and code completion will still index them.
Invert the responsibility of the entrypoint so that FrontendTool is directing the actual serialization work. The entrypoint now solely exists to construct a dependency graph.
While I'm here, prepare the way for serializing dependency graphs for modules by optimistically modeling a ModuleOrSourceFile input.
With this option enabled, the dependency scanner gathers all import statements in source files of the main module (non-transitive) and outputs a list of imported modules.
This will be used by build systems and the swift-driver as a way to avoid redundant re-scanning in incremental contexts.
For now, force the clang-based actions to skip the end of the pipeline. This restores the previous behavior of the frontend, but may not be desirable in the long run. For example, one may want to dump clang stats after running an -emit-pch job, but that is impossible without forcing the end of the pipeline to be more tolerant of ObjCHeader/modulemap-only inputs.
rdar://68587228
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.
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.
To help solving rdar://67079780, this change allows swift-driver to configure scanner using additional
arguments passed down via the batch input JSON file for each module under scanning.
This scanning mode allows swift-driver to query module dependencies in a batch
and in a more granular way. In short term, it could help solve a problem that
clang module dependencies may vary if target triple changes. In a longer term,
we could break a holistic dependencies graph into smaller pieces for better caching
and reusing.
This change doesn't include the implementation of using the specified scanner
arguments to set up Clang dependencies scanner. It will come in later commits.
For the issue mentioned in rdar://67079780, swift-driver needs to run clang dependencies
scanner multiple times with different target triples for a Swift target. This patch adds
a new scanning action to generate the JSON file for a given clang module to accommodate
this requirement.
Resolves: rdar://problem/67269210
