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.
Every call to lookupDirect() was calling prepareLookupTable() followed
by addLoadedExtensions(). While prepareLookupTable() only did its work
once, addLoadedExtensions() would walk all currently-loaded members of
all extensions every time.
However, just merging it with prepareLookupTable() was not enough,
because other places call prepareLookupTable(), which ends up loading
extensions too early after this change.
Instead, separate out the lazy allocation of the lookup table from
initialization. getLookupTable() returns a potentially-uninitialized
lookup table, and prepareLookupTable() now does what it did before
as well as what was formerly in addLoadedExtensions().
With this new split, getLookupTable() can be used instead of
prepareLookupTable() to avoid request cycles in a couple of places.
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
Previously, Swift would reject an `override public init(…)` in an `@_objcImplementation` because ClangImporter would have already synthesized inherited initializers that conflicted with the overrides. Ignore these spurious conflicts, and also move a check out of IsObjCRequest and into the conflict-handling code.
Additional work towards rdar://70730077.
