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.
Introduce discriminators into freestanding macro expansion expressions
and declarations. Compute these discriminators alongside closure and
local-declaration discriminators, checking them in the AST verifier.
The attached and freestanding macro attributes use the same parsing
logic and representation, so generalize the "attached" attribute into
a more general "macro role" attribute.
call it from parseExpandedAttributeList.
In the future, it would be much better to requestify computing exportedSourceFile,
so the new Swift parser is invoked on-demand rather than making sure it's
invoked in all of the appropriate parser entry points.
Describe attached macros with the `@attached` attribute, providing the
macro role and affected names as arguments to the macro. The form of
this macro will remain the same as it gains other kinds of attached
macro roles beyond "accessor".
Remove the "accessors" role from `@declaration`, which will be going
away.
Once an accessor macro has produced accessors, parse them and wire them
into the AST so the rest of the compiler will see them. First
end-to-end test case!
This is needed for general fidelity in SIL, since generic argument
lists are used for a lot of different things that aren't restricted
from containing multiple packs. I haven't actually done the work to
use Pack structure to disambiguate the resolution of pack parameters,
but this is a good start.
We'll probably need something like this in source eventually, so
there's no reason to regret adding all the infrastructure for it.
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.
Align the grammar of macro declarations with SE-0382, so that macro
definitions are parsed as an expression. External macro definitions
are referenced via a referenced to the macro `#externalMacro`. Define
that macro in the standard library, and recognize uses of it as the
definition of other macros to use externally-defined macros. For
example, this means that the "stringify" macro used in a lot of
examples is now defined as something like this:
@expression macro stringify<T>(_ value: T) -> (T, String) =
#externalMacro(module: "MyMacros", type: "StringifyMacro")
We still parse the old "A.B" syntax for two reasons. First, it's
helpful to anyone who has existing code using the prior syntax, so they
get a warning + Fix-It to rewrite to the new syntax. Second, we use it
to define builtin macros like `externalMacro` itself, which looks like this:
@expression
public macro externalMacro<T>(module: String, type: String) -> T =
Builtin.ExternalMacro
This uses the same virtual `Builtin` module as other library builtins,
and we can expand it to handle other builtin macro implementations
(such as #line) over time.
Always parse macro expansions, regardless of language mode, and
eliminate the fallback path for very, very, very old object literals
like `#Color`. Instead, check for the feature flag for macro
declaration and at macro expansion time, since this is a semantic
restriction.
While here, refactor things so the vast majority of the macro-handling
logic still applies even if the Swift Swift parser is disabled. Only
attempts to expand the macro will fail. This allows us to enable the
macro-diagnostics test everywhere.
