The runtime compat 5.6 library is not available in current toolchains.
The stage-0 compiler builds fine since the builder compiler is not aware
of the 5.6 library, but the stage-1 compiler will not link since the
builder libraries don't have the compat 5.6 library, while the stage-0
compiler is aware of the library and attempts to link it into the built
products. The issue is that the bootstrap goes and uses the libraries
off of the builder instead of the things that actually match the
compiler.
This is currently safe because the 5.6 compat library only contains
concurrency runtime fixes and the compiler frontend does not use
concurrency yet. If this changes, we will need to re-enable this and
make the bootstrap use the libraries correctly.
Rather than trying to patch up the "basic" macro expansion context
that comes from the swift-syntax package, implement our own based
on the new SourceManager. Fixes the `location(of:)` operation.
We can get into a situation where the C++ parser has emitted a warning but no error and thus `hadAnyError()` is still `false`. Suppress warnings from SwiftParser to avoid emitting the same warning that we already emitted from the C++ parser from SwiftParser.
Errors that were thrown out of a macro implementation were being
emitted and then lost. The result of this is a SILGen assertion later
on, if there were no other errors in the code.
Make sure we properly emit these diagnostics through the source
manager, which required fixing an issue in the offset computation used
for diagnostics.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Use the name mangling scheme we've devised for macro expansions to
back the implementation of the macro expansion context's
`getUniqueName` operation. This way, we guarantee that the names
provided by macro expansions don't conflict, as well as making them
demangleable so we can determine what introduced the names.
Add SourceManager that can keep track of multiple source file syntax
nodes along with their external representations. The source manager can
emit diagnostics into any of those files, including tracking any
explicitly "detached" syntax nodes used for macro expansion.
Make sure we detach syntax nodes before passing them to macro
implementations, so they cannot see more of the source file than they
are permitted. We hadn't been doing this before (by accident), and
doing so motivated the introduction of the SourceManager.
Additionally, perform operator folding on macro arguments as part of
detaching them. Macro clients shouldn't have to do this, and moreover,
when clients do this, they lose the ability to easily emit diagnostics
on the now-folded nodes.
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 `-`.
