Implement an ASTGen operation to bridge swift-syntax diagnostics, as
produced by the parser, operator folding, and macros, over to the C++
diagnostic engine infrastructure. Use this to wire up macro expansion
diagnostics.
The API provided by macro evaluation has changed a bit. Adapt ASTGen to
the new API, and use this as an opportunity to start moving more tests
to using the shared libraries built into the toolchain.
This approach works for both macros built into the compiler (e.g., the
builtin macros) as well as those that are loaded via plugin but don't
conform to the _CompilerPluginSupport protocol.
This eliminates all uses of the `MacroSystem` itself in ASTGen, and
pushes more of the implementation through ASTGen.
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
Enable type checking support for explicitly specifying generic arguments to
a macro, e.g., `#stringify<Double>(1 + 2)`. To do so, introduce a new
kind of constraint that performs explicit argument matching against the
generic parameters of a macro only after the overload is chosen.
The macro signature can depend on both the owning module and any
supplemental signature modules. Create import declarations for each of these
prior to import resolution of the macro signature buffer.
Allow more than one macro plugin to introduce a macro with the same
name, and let the constraint solver figure out which one to call. Also
eliminates a potential use-after-free if we somehow find additional
compiler plugins to load after having expanded a macro.
Plumb the information about the owning module and supplemental
signature modules through to the Macro data structure, for both
built-in and plugin macros.
We're resolving the given module names into module declarations, but
otherwise performing no checking and not emitting any diagnostics.
This information is not yet used.
Experimental features require an asserts build.
Fixes rdar://101790243 (Swift CI: experimental feature 'Macros'
cannot be enabled in a production compiler!
Type check user-defined macros plugins with user-provided type signatures.
Also, load plugin libraries with `RTLD_LOCAL` instead of `RTLD_GLOBAL` to prevent symbol collision between plugins. `llvm::sys::DynamicLibrary` only supports `RTLD_GLOBAL` so we use the plain `dlopen` instead. This does not work on Windows and needs to be fixed.
Friend PR: apple/swift-syntax#1042
Teach ASTScope how to reason about macro expansions. When we create an
ASTScope for a source file that represents a macro expansion, its
parent scope node is the macro expansion itself. When performing
unqualified lookup (of any form), find the starting source file based
on the location, not on the source file provided---this ensures that
we start lookups within the macro expansion (for example).
The effect of this is to enable macro expansions to work in nested
contexts, where they refer to names in the scope in which the macro is
expanded.
This is decidedly unhiegenic, but it fits with our syntactic model.
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
Once we have expanded an expression macro, parse and type-check the
result given a priori knowledge of the expanded type. Then, create an
implicit macro-expansion expression to capture the result of the
rewrite.
Introduce an experimental option `BuiltinMacros` that takes the magic
literals (`#file`, `#line`, `#function`, etc.) after type checking and
processes the original source for the expression using the build
syntactic macro system in the swift-syntax library. At present, the
result of expansion is printed to standard output, but it's enough to
verify that we're able to find the corresponding syntax node based on
the C++ AST.
