Allow `-typecheck-module-from-interface` using explicit module instead
of building implicit module.
This setups swift-frontend to accept explicit module build arguments and
loading explicit module during verifying. SwiftDriver needs to setup
correct arguments including the output path for swift module to fully
enable explicit module interface check.
`lib/swift/host` contains modules/libraries that are built by the host
compiler. Their `.swiftmodule` will never be able to be read, ignore
them entirely.
Add a CachedDiagnosticsProcessor that is a DiagConsumer can capture all
the diagnostics during a compilation, serialized them into CAS with a
format that can be replayed without re-compiling.
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.
* 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
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
In https://github.com/apple/swift/pull/42486 new behavior was introduced to ignore adjacent .swiftmodule files in the SDK. This behavior has caught a few people off guard so it seems like there should be diagnostics clarifying why a rebuild is occurring in this scenario.
Resolves rdar://105477473
Introduce a new flag `-export-as` to specify a name used to identify the
target module in swiftinterfaces. This provides an analoguous feature
for Swift module as Clang's `export_as` feature.
In practice it should be used when a lower level module `MyKitCore` is
desired to be shown publicly as a downstream module `MyKit`. This should
be used in conjunction with `@_exported import MyKitCore` from `MyKit`
that allows clients to refer to all services as being part of `MyKit`,
while the new `-export-as MyKit` from `MyKitCore` will ensure that the
clients swiftinterfaces also use the `MyKit` name for all services.
In the current implementation, the export-as name is used in the
module's clients and not in the declarer's swiftinterface (e.g.
`MyKitCore`'s swiftinterface still uses the `MyKitCore` module name).
This way the module swiftinterface can be verified. In the future, we
may want a similar behavior for other modules in between `MyKitCore` and
`MyKit` as verifying a swiftinterface referencing `MyKit` without it
being imported would fail.
rdar://103888618
A macro declaration contains the external module and type name of the
macro's implementation. Use that information to find the macro type
(via its type metadata accessor) in a loaded plugin, so we no longer
require the "allMacros" array. Instead, each macro implementation type
must be a public struct.
Since we are now fully dependent on the macro declaration for
everything about a macro except its kind, remove most of the query
infrastructure for compiler plugins.
Replace the macro registration scheme based on the allMacros array with
Prepare to accept the `ipi` argument to the `-library-level` flag. IPI
stands for Internal Programming Interface and would describe a module
that's not to be distributed outside of its project.
In the future, the compiler could use that information to report when a
distributed module (api or spi) imports publicly a module that's not
distributed.
rdar://102435183
Allow user-defined macros to be loaded from dynamic libraries and evaluated.
- Introduce a _CompilerPluginSupport module installed into the toolchain. Its `_CompilerPlugin` protocol acts as a stable interface between the compiler and user-defined macros.
- Introduce a `-load-plugin-library <path>` attribute which allows users to specify dynamic libraries to be loaded into the compiler.
A macro library must declare a public top-level computed property `public var allMacros: [Any.Type]` and be compiled to a dynamic library. The compiler will call the getter of this property to obtain and register all macros.
Known issues:
- We current do not have a way to strip out unnecessary symbols from the plugin dylib, i.e. produce a plugin library that does not contain SwiftSyntax symbols that will collide with the compiler itself.
- `MacroExpansionExpr`'s type is hard-coded as `(Int, String)`. It should instead be specified by the macro via protocol requirements such as `signature` and `genericSignature`. We need more protocol requirements in `_CompilerPlugin` to handle this.
- `dlopen` is not secure and is only for prototyping use here.
Friend PR: apple/swift-syntax#1022
Controlled with a new flag '-direct-clang-cc1-module-build'
This will allow clients to formulate 'swift-frontend' invocations with fully-specified set of cc1 arguments (using '-Xcc -Xclang -Xcc <FLAG>') required for the PCM build, without having to go through the driver.
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
Prebuilt modules are only available for certain toolchain and SDK combinations. Therefore,
building modules from interface, even for the stdlib, is expected to happen.
related: rdar://96701615
Experimental features can only be enabled in non-production (+Asserts)
builds. They can be detected with `hasFeature` in the same manner as
"future" features.
The `-enable-experimental-feature X` flag will also look for future
features by that name, so that when an experimental feature becomes an
accepted future feature, it will still be enabled in the same manner.
Switch variadic generics over to this approach, eliminating the
specific LangOption for it.
