The SwiftDiagnostics module within swift-syntax has a diagnostic
pretty-printer that does a nice rendering of the source code with
diagnostics placed inside gaps between the code lines.
Introduce another `-diagnostic-style` argument, `swift-syntax`,
to bridge from the pretty-printed C++ diagnostics over to the
swift-syntax diagnostics engine.
Attribute macros are expanded during AttachedSemanticAttrsRequest. This
change invokves the expansion, but it does nothing with the result yet.
The next step is to parse back in the attribute list, type check it, and
return the resulting attributes back to the request to add to the semantic
attribute list.
Accessor macros are attached macros (written with attribute syntax)
that can generate accessors for a property or subscript. Recognize
custom attributes that are accessor macros when written on a storage
declaration, and expand those macros.
This is very much a work in progress, and the result of the expansion
isn't yet parsed or wired into the AST.
Add support for freestanding declaration macros.
- Parse `@declaration` attribute.
- Type check and expand `MacroExpansionDecl`.
Known issues:
- Generic macros are not yet handled.
- Expansion does not work when the parent decl context is `BraceStmt`. Need to parse freestanding declaration macro expansions in `BraceStmt` as `MacroExpansionDecl`, and add expanded decls to name lookup.
pack expansion type reprs.
Classic variadic parameters still use the postfix ellipsis syntax, and
pack expansion types now use a prefix 'repeat' keyword.
The swift-syntax diagnostic system always treats Fix-Its as separate
notes, which are never attached to the primary diagnostic. Embrace this
module in the mapping over to the existing C++ diagnostic engine.
Replace the use of the "consistency check" vended by swift-syntax with
an ASTGen-implemented operation that emits diagnostics from the new parser
via the normal diagnostic engine. This eliminates our last dependency
on SwiftCompilerSupport, so stop linking it.
"Relink" the folded syntax node back into the primary syntax node. When
we do this, we get consistent source locations that do not require any
adjustment.
Test this by adding a Fix-It to the silly AddBlocker macro, replacing
the `+` with a `-`.
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.
Make the build directory for lib/swift/host look like the eventually
toolchain directory by copying in all of the Swift module files. This
makes it easier to correctly build anything requiring these libraries
against either the build or the install directories.
This allows the various binaries (swift-frontend, SourceKit, etc.) to
share the same code, as well as allowing plugins to link against these
shared libraries.
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.
