Eliminate a source of cyclic dependencies by not expanding macros when
we are resolving macro arguments within a type or extension context.
This extends the scheme introduced for module-scope lookup to also
apply to lookup within types.
The macro name resolution in the source lookup cache was only looking at
macros in the current module, meaning that any names introduced by peer
or declaration macros declared in one module but used in another would
not be found by name lookup.
Switch the source lookup cache over to using the same
`forEachPotentialResolvedMacro` API that is used by lookup within
types, so we have consistent name-lookup-level macro resolution in both
places.
... except that would be horribly cyclic, of course, so introduce name
lookup flags to ignore top-level declarations introduced by macro
expansions. This is semantically correct because macro expansions are
not allowed to introduce new macros anyway, because that would have
been a terrible idea.
Fixes rdar://107321469. Peer and declaration macros at module scope
should work a whole lot better now.
Some lookups, such as the ones used for protocol conformance checking,
provide full names (with arguments). Drop everything down to simple names
so they we don't skip macro expansions when we might need them.
When populating the name lookup tables with macro-expanded declarations,
we were careful to avoid full macro resolution for attached macros, but
freestanding macros were will doing full resolution. Switch
freestanding macros over to the same partial resolution mechanism to
avoid reference cycles.
Rather than eagerly expanding all member macros when doing any name
lookup into a type, use the same introduced-name-tracking logic we
apply to peer macros to only expand those member macros that can
produce the requested name. This makes the compiler lazier.
Ensure that name lookup triggers the expansion of member macros on
extensions, so we can find those names. And fix a bug that caused
expansion of member macros to crash.
When populating the name lookup tables for a nominal type, we were only
visiting declarations with peer macros within the nominal type
declaration itself. Also visit the members of extensions of the
nominal type.
Without this change, peer-macro-defined members of extensions are not
visible.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
Always use `Decl::visitAuxiliaryDecls` to visit decls produced by macros, including peer macros and declaration macros. Use name-driven expansion for peer macros. Remove `MacroExpansionDecl::getRewritten()`.
Also make `ExpandMacroExpansionDeclRequest` cache the buffer ID (similar to other macros) instead of an array of decls.
Always use `Decl::visitAuxiliaryDecls` to visit decls produced by macros, including peer macros and declaration macros. Use name-driven expansion for peer macros. Remove `MacroExpansionDecl::getRewritten()`.
Also make `ExpandMacroExpansionDeclRequest` cache the buffer ID (similar to other macros) instead of an array of decls.
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
This lets us consolidate code paths that mostly run in parallel over the
existing InOutTypeRepr/SharedTypeRepr/OwnedTypeRepr family of types. This
patch by itself is NFC but makes it easier to introduce new spellings,
particularly the newly-official `borrowing` and `consuming` modifiers
that were approved in SE-0377.
The macro role argument presented an opportunity for callers to accidentally
invoke this request twice for the same macro with slightly different macro
roles passed in, which resulted in re-typechecking the macro arguments.
Instead, derive the corresponding macro roles from the macro reference syntax.
The result values of the expansion requests for attached macros tended
to be useless, because most of their operation is via side effects on
the nodes they are attached to. Replace the result values with an
array of expansion buffer IDs, so clients can see what effect the
macro expansion had.
- Use the name lookup table instead of adding members from a macro expansion to the parent decl context.
- Require declaration macros to specify introduced names and used the declared names to guide macro expansions lazily.
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.
Macro attribute lookup is now implemented in ResolveMacroRequest, which happens
later because it needs overload resolution to resolve a custom attribute to a
macro decl.
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.
Introduce appropriate name lookup for custom attributes to find macros
at module scope, and prefer those to types of the same name. We don't
do anything with the macros we found other than ignore them, for the
moment.
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.
