Teach swift dependency scanner to use CAS to capture the full dependencies for a build and construct build commands with immutable inputs from CAS.
This allows swift compilation caching using CAS.
Instead of being a part of 'directDependencies' on a module dependency info, make them a separate array of dependency IDs for Swift Source and Textual modules.
This will allow clients to still distinguish direct module dependencies imported from a given module, versus dependencies added because direct/transitive Clang module dependencies have Swift overlays.
This change does *not* remove overlay dependencies from 'directDependencies' yet, just adds them as a separate field on the module details info. A followup change will remove overlay and bridging header dependencies from 'directDependencies' once the clients have had a chance to adopt to this change.
This new version takes the path to the compiler executable as a parameter, in order for libSwiftScan to compute compiler-relative portions of runtimeLibraryPaths, runtimeResourcePath. V1, without knowing the path to the compiler executable, produced incomplete sets of these paths.
Previously no API returned a raw 'swiftscan_string_ref_t' directly so this was not needed.
However, 'swiftscan_compiler_target_info_query' returns a string directly, which the clients need to clean up.
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
This adds C functions that can be called from SwiftSyntax to enable or disable bare slash regex parsing.
It also adds a function to set the Swift language version - while this is not of top priority at the moment it will become important once we introduce a new language mode again.
rdar://93750821
This separates it from `libSwiftScan` and allows us to build this library without building much of the rest of the compiler.
Also refactor `utils/build-parser-lib` into `utils/build-tooling-libs` which builds both SwiftSyntaxParser and SwiftStaticMirror.
This commit adds new entry-points to `libSwiftScan` that operate on the new BinaryScanningTool, which reads out Swift type information from object files, starting with a query of all protocol conformances.
To split the SwiftSyntax library into two modules – `SwiftSyntax` with no dependency on `_InternalSwiftSyntaxParser.dylib` and `SwiftSyntaxParser` which generates a `SwiftSyntax` tree using `_InternalSwiftSyntaxParser.dylib` – we need to copy the definition of the C types into the SwiftSyntax repository. To make sure the two match, move the duplicated types into their own file. That way, we can compare them in SwiftSyntax’s build script and thus make sure their definitions are the same.
Doing so will allow clients to know which Swift-specific PCM arguments are already captured from the scan that first discovered this module.
SwiftDriver, in particular, will be able to use this information to avoid re-scanning a given Clang module if the initial scan was sufficient for all possible sets of PCM arguments on Swift modules that depend on said Clang module.
These kinds of modules differ from `SwiftTextual` modules in that they do not have an interface and have source-files.
It is cleaner to enforce this distinction with types, instead of checking for interface optionality everywhere.
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.
We don't actually need the range for layout nodes, so just store it
for token nodes. This will also make deferred node handling easier
later on, because we don't need to keep track of layout node ranges.
Previously, the passed in source file was implicitly terminated by the
first null character. The source file might, however, contain a null
character in the middle and we shouldn't stop parsing at it.
It is not a distinct result returned by `swiftscan_compiler_supported_arguments_query` and `swiftscan_compiler_supported_features_query`, not owned by any other type, so it must be disposed of by the clients.
For the client library (`libSwiftDriver`), this is critical for multiplexing library instances, and for compatibility with different versions of `libSwiftDrvier`.
Resolves rdar://73631930
This library now relires on a static compiler library called `swiftDependencyScan`, which is also common to being used by `swift-frontend` for its dependency scanner invocations.
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.
