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
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.
The macro signature context was a (possibly generic) struct declaration
containing a typealias. We don't need the struct itself, because the
typealias can be generic as well. This eliminates an extra, annoying
hop through name lookup.
We had two implementations of the code that forms the macro evaluation
context buffer, one in ASTGen and one in Sema. Unify them into a single
place, and unify the creation of macros so we localize this arcane
knowledge.
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
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.
Rework the ASTGen interface to split apart parsing a source file,
turning the top-level declarations from that source file into C++ AST
nodes, and then deallocating that source file. Hold on to the source
file in the C++ SourceFile abstraction so we can query it later if we
need to.
And we will need to.
Only introduce it and its dependency when the new Swift parser is being
built, and rely more on existing logic to make sure we get the right
build/link flags.
