https://github.com/apple/swift/pull/37774 (related to rdar://72480261) has made it so that the target of built clang modules (even downstream from Swift interface dependencies) can be consistent with that of the main module. This means that when building transitive Clang dependencies of the main module, they will always have a matching triple to the main module itself (ensured with `-clang-target`). This means we no longer have to report the target triple in the set of `extraPCMArgs` which encode an interface-specific requirement for building its dependencies.
Using the serialization format added in https://github.com/apple/swift/pull/37585.
- Add load/save code for the `-scan-dependencies` code-path.
- Add `libSwiftDriver` entry-points to load/store the cache of a given scanner instance.
This mechanism allows the compiler to use a backup interface file to build into a binary module when
a corresponding interface file from the SDK is failing for whatever reasons. This mechansim should be entirely opaque
to end users except several diagnostic messages communicating backup interfaces are used.
Part of rdar://77676064
This will enable users to try out the '-enable-ossa-modules' flag if their
compiler supports it and get OSSA code on all inlinable code that they use. The
idea is that this is a nice way to stage this in and get more testing.
The specific implementation is that the module interface loader:
1. Knows if enable ossa modules is enabled not to search for any compiled
modules. We always rebuild from the interface file on the system.
2. Knows that if enable ossa modules is enabled to mixin a bit into the module
interface loader cache hash to ensure that we consider the specialized ossa
compiled modules to be different than the modules in that cache from the system.
This ensures that when said flag is enabled, the user transparently gets all
their code in OSSA form from transparent libraries.
We must reset option occurences on each entry because we are handling an unrelated command-lines to those parsed before. We must do so because LLVM options parsing is done using a managed static `GlobalParser`.
Resolves rdar://75247030
Additional arguments that the compiler must pass to the Clang Importer (Clang dep scanner), incl. search paths, must come from the invocation that launched the scan in order to correctly match the specific target being scanned, instead of re-using those from a cached CompilerInstance.
The intent is two-fold:
1. This fixes a bug where we would only attempt to resolve direct dependencies as Clang modules for Swift Binary modules.
2. Ensures that we only query the presence of a Bridging Header for textual Swift modules.
Resolves rdar://73015075
This speeds up contexts where we need to resolve dependencies after the main scanning action is complete.
For example: libSwiftScan binary graph generation and cycle detection.
This is necessary because ordinarily, ModuleDependenciesCache must be queried on a per-loader basis.
For example, we first search for Swift modules with the SerializedModuleLoaderBase, at which point we check the cache for previously-found Swift modules. If cache is not hit, we search the filesystem.
Then we search for Clang moduels with the ClangLoader, at which point we check the cache for previously-found Clang modules. If cache is not hit, we search the filesystem.
This change allows to eliminate a bunch of filesystem searching in step (1) when we know we have completed the scan and no longer need to be concerned with the correctness of the cache contents.
Adds a C API layer consisting of:
- Data structures used to represent in-memory result of dependency scanning
- Opaque dependency scanner tool (C wrapper for `DependencyScanningTool`)
Refactors `ScanDependencies.cpp` to produce dependency scanning result in the form of the above binary format.
This commit refactors ScanDependencies.cpp to split the functionality into two functional groups:
- Scan execution code that performs the mechanics of the scan and produces an in-memory result
- Dependency scanner entry-points used when the scanning action is invoked as a `swift-frontend` execution mode
This commit also adds the aforementioned in-memory dependency scanning result in `FullDependencies.h`, modeled after the InterModuleDependencyGraph representation in swift-driver
