An "API descriptor" file is JSON describing the externally accessible symbols
of a module and metadata associated with those symbols like availability and
SPI status. This output was previously only generated by the
`swift-api-extract` alias of `swift-frontend`, which is desgined to take an
already built module as input. Post-processing a built module to extract this
information is inefficient because the module and the module's dependencies
need to be deserialized in order to visit the entire AST. We can generate this
output more efficiently as a supplementary output of the -emit-module job that
originally produced the module (since the AST is already available in-memory).
The -emit-api-descriptor flag can be used to request this output.
This change lays the groundwork by introducing frontend flags. Follow up
changes are needed to make API descriptor emission during -emit-module
functional.
Part of rdar://110916764.
Conflict in CAS options when
`std::vector<std::string> CacheReplayPrefixMap;` was added.
Conflicts:
include/swift/Frontend/FrontendOptions.h
Resolution: Take both
Using `-Rmodule-api-import` the compiler prints a remark about the
import bringing in every decl used in public function signatures or
inlinable code. It also remarks on the source of conformances where they
are used and the source of typealias underlying types.
Teach CachedDiagnosticsProcessor to replay diagnostics for all consumers
with a different path using a path prefix map. This allows diagnostics
to be replayed for the actual path on disk after the scanner
canonicalized the path for compilation.
Allow DependencyScanner to canonicalize path using a prefix map. When
option `-scanner-prefix-map` option is used, dependency scanner will
remap all the input paths in following:
* all the paths in the CAS file system or clang include tree
* all the paths related to input on the command-line returned by scanner
This allows all the input paths to be canonicalized so cache key can be
computed reguardless of the exact on disk path.
The sourceFile field is not remapped so build system can track the exact
file as on the local file system.
The original `--ld-path` option hasn't been included in a released version yet, so it's ok to break.
The vast majority of other options on Swift Driver already use a single dash.
To enable MCCAS, the following driver options have been added
-cas-backend: Enable MCCAS backend in swift, the option
-cache-compile-job must also be used.
-cas-backend-mode=native: Set the CAS Backend mode to emit an object
file after materializing it from the CAS.
-cas-backend-mode=casid: Emit a file with the CASID for the CAS that was
created.
-cas-backend-mode=verify: Verify that the object file created is
identical to the object file materialized from the CAS.
-cas-emit-casid-file: Emit a .casid file next to the object file when
CAS Backend is enabled.
Macro implementations can come from various locations associated with
different search paths. Add a frontend flag `-Rmacro-loading` to emit
a remark when each macro implementation module is resolved, providing
the kind of macro (shared library, executable, shared library loaded
via the plugin server) and appropriate paths. This allows one to tell
from the build load which macros are used.
Addresses rdar://110780311.
This action is currently just an alias of the `-resolve-imports` action.
However, it's named to more clearly reflect the purpose which is to do the
minimal typechecking needed in order to emit the requested outputs. This mode
is intended to improve performance when emitting `.swiftinterface` and `.tbd`
files.
Frontend options should only be printed under `swift-module-flags-ignored:`
temporarily to prevent condfails for older development compilers that are still
in use (as a rule of thumb, swiftinterfaces should be compatible with compilers
that are up to 6 months old). None of the frontend flags that are currently
categorized as "ignorable" need to be ignorable anymore.
Instead of the code querying the compiler's built-in Clang instance, refactor the
dependency scanner to explicitly keep track of module output path. It is still
set according to '-module-cache-path' as it has been prior to this change, but
now the scanner can use a different module cache for scanning PCMs, as specified
with '-clang-scanner-module-cache-path', without affecting module output path.
Resolves rdar://113222853
Clang dependency scanning produces scanner PCMs which we may want to live in a
different filesystem location than the main build module cache.
Resolves rdar://113222853
Ensure that we process `-libc` in `swift-symbolgraph-extract` and
`swift-api-extract`. This option is used by Windows to determine the C
ABI to use and thus impacts the ABI exposed by the ClangImporter to the
Swift interface. This partially enables the use of
`swift package dump-symbol-graph` on Windows.
Rename `-enable-cas` to `-compile-cache-job` to align with clang option
names and promote that to a new driver only flag.
Few other additions to driver flag for caching behaviors:
* `-compile-cache-remarks`: now cache hit/miss remarks are guarded behind
this flag
* `-compile-cache-skip`: skip replaying from the cache. Useful as a
debugging tool to do the compilation using CAS inputs even the output
is a hit from the cache.
'load-plugin-library', 'load-plugin-executable', '-plugin-path' and
'-external-plugin-path' should be searched in the order they are
specified in the arguments.
Previously, for example '-plugin-path' used to precede
'-external-plugin-path' regardless of the position in the arguments.
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.
Deserialization recovery silently drops errors and the affected decls.
This can lead to surprises when a function from an imported module
simply disappears without an explanation.
This commit introduces the flag -Rmodule-recovery to report as remarks
some of these previously silently dropped issues. It can be used to
debug project configuration issues.
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.
Teach swift compiler about CAS to allow compiler caching in the future.
1) Add flags to initiate CAS inside swift-frontend
2) Teach swift to compile using a CAS file system.
