Currently headers produced with `-emit-objc-header` /
`-emit-objc-header-path` produce headers that include modular imports.
If the consumer wishes to operate without modules enabled, these headers
cannot be used. This patch introduces a new flag
(`-emit-clang-header-nonmodular-includes`) that when enabled
attempts to argument each modular import included in such a header with
a set of equivalent textual imports.
Ambiguities are introduced in generated swiftinterfaces when a type
shares a name with a module (i.e. XCTest). This workaround uses the
module-alias feature to avoid these ambiguities. Writing module
references with a distinguishable prefix should allow normal
type-checking to avoid the usual ambiguities.
We should still aim for a proper fully-qualified named syntax, but this
may help in the mean time.
rdar://101969500
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
Intro ASTContext::setIgnoreAdjacentModules to change module loading to
accept load only resilient modules from their swiftinterfaces, ignoring
the adjacent module and any silencing swiftinterfaces errors.
The relationship between the code in these two libraries was fundamentally circular, indicating that they should not have been split. With other changes that I'm making to remove circular dependencies from the CMake build graph I eventually uncovered that these two libraries were required to link each other circularly, but that had been hidden by other cycles in the build graph previously.
Previously, when evaluating a `#if canImport(Module, _version: 42)` directive the compiler could diagnose and ignore the directive under the following conditions:
- The associated binary module is corrupt/bogus.
- The .tbd for an underlying Clang module is missing a current-version field.
This behavior is surprising when there is a valid `.swiftinterface` available and it only becomes apparent when building against an SDK with an old enough version of the module that the version in the `.swiftinterface` is too low, making this failure easy to miss. Some modules have different versioning systems for their Swift and Clang modules and it can also be intentional for a distributed binary `.swiftmodule` to contain bogus data (to force the compiler to recompile the `.swiftinterface`) so we need to handle both of these cases gracefully and predictably.
Now the compiler will enumerate all module loaders, ask each of them to attempt to parse the module version and then consistently use the parsed version from a single source. The `.swiftinterface` is preferred if present, then the binary module if present, and then finally the `.tbd`. The `.tbd` is still always used exclusively for the `_underlyingVersion` variant of `canImport()`.
Resolves rdar://88723492
This patch gets everything to the point of building the library, but it
doesn't run yet since I have missing symbols.
Unlike previous compatibility libraries and the concurrency
compatibility library, I'm organizing the headers a bit more. This is
because we're merging the two libraries into one. They share some common
header names, and while I could rename them for namespacing purposes,
it's easier to just use a directory structure for this.
The `include/Runtime` and corresponding `Runtime/` directories are for
backdeployed changes to the stdlib itself.
The `include/Concurrency` and corresponding `Concurrency/` directories
are for backdeployed changes to the concurrency runtimes.
* Lookup for custom derivatives in non-primary source files after typecheck is finished for the primary source.
This registers all custom derivatives before autodiff transformations and makes them available to them.
Fully resolves#55170
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
You can now put `||` between two fix-its to indicate that the test succeeds if either of them is present. This is meant for situations where a fix-it might vary slightly in different subtests or test configurations.
Also fixes a bug in the diagnostic verifier where "expected-whatever" would search beyond the same line for its opening "{{", potentially finding one many lines away and giving a bad diagnostic and poor recovery behavior.
ABI descriptors should always be emitted as sidecars for library-evolution-enabled modules.
However, generating these files requires traversing the entire module (like indexing), which may
hit additional deserialization issues. To unblock builds, this patch introduces a flag to skip
the traversing logic so that we emit an empty ABI descriptor file. The empty file serves as
a placeholder so that build system doesn't need to know the details.
While implicitly building .swiftinterface, the interface may import other binary modules.
These binary modules may contain serialized search paths that have been obfuscated. To help
interface building commands recover these search paths, we need to pass down the obfuscators
to the module building commands.
rdar://87840268
