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.
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.
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.
One of the intended usages of `getRuntimeDiscoverableAttrTypeDecl`
is IRGen where we need to relate unique attributes to a list of their
(decl) attachments.
That does not work if there is a resilient class in the hiearchy from a
different module than the testable imported one. Rather treat an
internal but testable imported class as having resilient metadata.
The scenario that does not work assuming we can build a fragile layout
is the following.
FrameworkA is resilient and defines a public class `Base` with a stored field.
FrameworkB is resilient and defines an internal class `Sub` that inherits from
the class `Base` in FrameworkA and adds some fields. FrameworkB is compiled
with enable-testing.
The test case testable imports FrameworkB and accesses a field in the
internal class `Base` from FrameworkB. The test case only has access to
FrameworkA's public swiftinterface file and therefore does not know
`Base`'s layout. The layout computation for `Sub` cannot take the field
from `Base` into account and things fail silently.
rdar://103323275
`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
