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.
This disables TBD validation when C++ interop is enabled, unless an explicit `-validate-tbd-against-ir=` flag was passed.
rdar://83405989 / https://github.com/apple/swift/issues/56458
On both input moduel source-files and interface files.
This currently yields dramatic scanning performance improvements at no cost - we do not require an AST during scan.
Previously we would only enable by default when
`parseArgs` was called. However this wouldn't
enable it for clients such as LLDB, who provide
their own invocation. Switch the default to `true`
in the `LangOptions`, and remove some redundant
uses of `-enable-experimental-string-processing`.
The frontend flag remains, as it may be useful to
disable.
rdar://107419385
rdar://101765556
I want to reserve Feature::MoveOnly only for move-only types and other
things that are part of SE-390. Other prototyped features like
noimplicitcopy and some older names for consume were left behind
as guarded by this Feature. That's really not the right way to do it,
as people will expect that the feature is enabled all the time, which
would put those unofficial features into on-by-default. So this change
introduces two new Features to guard those unofficial features.
* Argument to '-load-plugin-library' now must have a filename that's
'{libprefix}{modulename}.{sharedlibraryextension}'
* Load '-load-plugin-library' plugins are now lazily loaded in
'CompilerPluginLoadRequest'
* Remove ASTContext.LoadedSymbols cache because they are cached by
'ExternalMacroDefinitionRequest' anyway
* `-load-plugin-executable` format validation is now in
'ParseSearchPathArgs'
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 attribute was commented out in the private swiftinterface for
backwards compatibility with older compilers unaware of the attribute.
This scenario shouldn't be a problem anymore and without that attribute
some imports can raise errors. Let's print the attribute as it was
written in the sources without commenting it out.
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.
Modules loaded from the resource dir are not usually rebuilt from the
swiftinterface as it would indicate a configuration problem. Lift that
behavior for SDK mismatch and still rebuild them.
This use case applies when a toolchain is used with a different SDK than
the one use to build the modules in the toolchain.
rdar://106101760
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
We're going to move toward the new swift-syntax formatter. Use it for
the "swift" diagnostic style instead of the experimental formatter
written in C++.
There are some tests for the experimental formatter in C++ that test
precise formatting of diagnostics. I've disabled them in the same
places where the new swift-syntax formatter is enabled, for now. We
may choose to remove them entirely, because swift-syntax itself is
where the specific format is defined, and has those same kinds of
tests already.
This mode allows the user to fallback to the old behavior that required @expose annotations, while still having standard library interfaces emitted in one header
