Intro a deserialization mode controlled by the flag
`-experimental-force-workaround-broken-modules` to attempt unsafe
recovery from deserialization failures caused by project issues.
The one issue handled at this time is when a type moves from one module
to another. With this new mode the compiler may be able to pick a
matching type in a different module. This is risky to use, but may help
in a pinch for a client to fix and issue in a library over which they
have no control.
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.
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
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
The frontend option '-clang-header-expose-module' allows the user to specify that APIs from an imported module have been exposed in another generated header, and thus APIs that depend on them can be safely exposed in the current generated header.
This modifies the ClangImporter to introduce an opaque placeholder
representation for forward declared Objective-C interfaces and
protocols when imported into Swift.
In the compiler, the new functionality is hidden behind a frontend
flag -enable-import-objc-forward-declarations, and is on by default
for language mode >6.
The feature is disabled entirely in LLDB expression evaluation / Swift
REPL, regardless of language version.
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.
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
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.
