Introduce discriminators into freestanding macro expansion expressions
and declarations. Compute these discriminators alongside closure and
local-declaration discriminators, checking them in the AST verifier.
Having a request for semantic declaration attributes while still allowing
the original linked list to be mutated directly can cause use-after-frees
on pointers to old decl attributes. For now, introduce a request that
expands member attribute macros with a side effect of adding the new
attributes to the list. We can revisit this once attribute mutation via
getAttrs() is audited across the frontend.
Introduce 'getSemanticAttrs', which is a requestified replacement for
'getAttrs'. Right now, AttachedSemanticAttrsRequest calls 'getAttrs',
meaning future additions or removals from the linked list will not be
reflected via 'getSemanticAttrs'. Callers of 'getAttrs' that rely on
mutation will need to turn the computation into a request and vend the
attributes through AttachedSemanticAttrsRequest.
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.
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.
Adopt new request-based utilities for looking up the enclosing declaration's availability when type checking an `@available` attribute. This consolidates implementations of the lookup and improves diagnostics by catching more cases where declarations are more available than their containers.
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.
Local discriminators for named entities are currently being set by the
parser, so entities not created by the parser (e.g., that come from
synthesized code) don't get local discriminators. Moreover, there is
no checking to ensure that every named local entity gets a local
discriminator, so some entities would incorrectly get a local
discriminator of 0.
Assign local discriminators as part of setting closure discriminators,
in response to a request asking for the local discriminator, so the
parser does not need to track this information, and all local
declarations---including synthesized ones---get local discriminators.
And add checking to make sure that every entity that needs a local
discriminator gets assigned one.
There are a few interesting cases in here:
* There was a potential mangling collision with local property
wrappers because their generated variables weren't getting local
discriminators
* $interpolation variables introduced for string interpolation weren't
getting local discriminators, they were just wrong.
* "Local rename" when dealing with captures like `[x]` was dependent on
the new delcaration of `x` *not* getting a local discriminator. There
are funny cases involving nesting where it would do the wrong thing.
Single expression is not going to cut it in this case because attribute
and attached declaration could have different availability, so we need
to use `if #available` to guard attribute instantiation and return `nil`
in cases where types are not available.
The runtime discoverable attribute generator just like a default
argument or a property wrapper doesn't have a distinct name or
a declaration. Sema should synthesize a call that could be used
to obtain a value of an attribute type and everything else is
going to be synthesized in SILGen.
One of the intended usages of `getRuntimeDiscoverableAttrTypeDecl`
is IRGen where we need to relate unique attributes to a list of their
(decl) attachments.
The request is updated to return attribute, wrapper declaration,
the declaration its attached to and whether or not it has been
inferred (opposite to being declared directly).
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.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
getPotentiallyOpaqueGenericParams has a redundant call to check if
declarations contain any opaque type representations. We don't need
to check this here. Instead we can simply collect the result type
representaions without the additional checks.
Although the declaration of macros doesn't appear in Swift source code
that uses macros, they still operate as declarations within the
language. Rework `Macro` as `MacroDecl`, a generic value declaration,
which appropriate models its place in the language.
The vast majority of this change is in extending all of the various
switches on declaration kinds to account for macros.
Adding a type wrapper attribute on a protocol does two things:
- Synthesizes `associatedtype $Storage` declaration with `internal` access
- Synthesizes `var $storage: <#Wrapper#><Self, Self.$Storage>` value requirement
