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.
The functionality for this flag is no longer necessary because the emit module jobs for deprecated architectures no longer use an artificially low deployment target.
Resolves rdar://104758113
This executable is intended to be installed in the toolchain and act as
an executable compiler plugin just like other 'macro' plugins.
This plugin server has an optional method 'loadPluginLibrary' that
dynamically loads dylib plugins.
The compiler has a newly added option '-external-plugin-path'. This
option receives a pair of the plugin library search path (just like
'-plugin-path') and the corresponding "plugin server" path, separated
by '#'. i.e.
-external-plugin-path
<plugin library search path>#<plugin server executable path>
For exmaple, when there's a macro decl:
@freestanding(expression)
macro stringify<T>(T) -> (T, String) =
#externalMacro(module: "BasicMacro", type: "StringifyMacro")
The compiler look for 'libBasicMacro.dylib' in '-plugin-path' paths,
if not found, it falls back to '-external-plugin-path' and tries to find
'libBasicMacro.dylib' in them. If it's found, the "plugin server" path
is launched just like an executable plugin, then 'loadPluginLibrary'
method is invoked via IPC, which 'dlopen' the library path in the plugin
server. At the actual macro expansion, the mangled name for
'BasicMacro.StringifyMacro' is used to resolve the macro just like
dylib plugins in the compiler.
This is useful for
* Isolating the plugin process, so the plugin crashes doesn't result
the compiler crash
* Being able to use library plugins linked with other `swift-syntax`
versions
rdar://105104850
This adds the following four new options:
- `-windows-sdk-root`
- `-windows-sdk-version`
- `-visualc-tools-root`
- `-visualc-tools-version`
Together these options make one the master of Windows SDK selection for
the Swift compilation. This is important as now that the injection is
no longer done by the user, we need to ensure that we have enough
control over the paths so that the synthesized overlay is going to map
the files to the proper location.
Add '-validate-clang-modules-once' and '-clang-build-session-file' corresponding to Clang's '-fmodules-validate-once-per-build-session' and '-fbuild-session-file='. Ensure they are propagated to module interface build sub-invocations.
We require these to be first-class Swift options in order to ensure they are propagated to both: ClangImporter and implicit interface build compiler sub-invocations.
Compiler portion of rdar://105982120
* Remove support for linking arclite
Darwin no longer uses arclite and it's no longer distributed
in the macOS SDKs.
This leaves the options -link-objc-runtime and -no-link-objc-runtime
in place, but strips out all the logic that actually used them.
* Remove a dead function
* Warn if `-link-objc-runtime` is used
* Update tests to not look for arclite library
* Add an explicit test for the deprecation warning
* Move the macOS-only -link-objc-runtime test to a separate test file
Add a compiler option `-load-plugin-executable <path>#<module names>`.
Where '<path>' is a path to a plugin executable, '<module-name>' is a
comma-separated module names the plugin provides.
Nothing is using it at this point. Actual plugin infratructure are
introduced in follow-up commits
Introduce `-plugin-path <path>` to add a search path where we will look
for compiler plugins. When resolving an external macro definition, look
for libraries in these search paths whose names match the module name
of the macro.
Implements rdar://105095761.
