The mangling of macro expansions relies on having a type-checked AST
for its enclosing context. When that enclosing context is within a
local context (say, a local type), mangling would trigger type
checking of that local type, which could then involve assigning local
discriminators. However, if this happens before type checking of the
enclosing function body, we would end up failing to assign closure
discriminators to (e.g.) autoclosures within the body.
The fundamental problem here is the interaction between discriminator
assignment (which can only happen after type checking) and mangling of
macro expansion buffers (which can happen during that type checking).
Break this cycle by providing a different approach to mangling macro
expansions within local contexts as the innermost non-local context +
a name-based discriminator within that local context. These manglings
are not ABI and are not stable, so we can adjust them later if we come
up with a scheme we like better. However, by breaking this cycle, we
eliminate assertions and miscompiles that come from missing
discriminators in this case.
Fixes rdar://139734958.
In this PR i worked on replacing the word accessor in diagnostics with more user-facing terminologies like setter, getter, didSet Observer, and members based on the context of the message.
in some messages i didn't need to pass DescriptiveDeclKind instead i just changed the text copy itself.
i also updated tests, so you might find it easier to check my changes this way.
Please let me know if there's something i should've done in a better way, and request changes if needed. !
i can squash my commits after reviewing getting the PR Reviewed, just to make it easier to be checked commit by commit
Resolves#55887
As with property wrappers, we can't properly desugar the application of
accessor macros to bindings with multiple variables. Prohibit them up
front.
Fixes rdar://112783811.
The checking of the accessors generated by a macro against the
documented set of accessors for the macro is slightly too strict and
produces misleading error messages. Make the check slightly looser in
the case where an observer-producing macro (such as
`@ObservationIgnored`) is applied to a computed property. Here, we
would diagnose that the observer did not in fact produce any
observers, even though it couldn't have: computed properties don't get
observers. Remove the diagnostic in this case.
While here, add some tests and improve the wording of diagnostics a
bit.
Fixes rdar://113710199.
This could also use `%kind` for the declaration kind, but that ends up
being "extension of struct" instead of just "extension", which seems
slightly worse.
As with the initial value of a property that is converted from a stored
property to a computed property by an accessor macro, remove
didSet/willSet. It is the macro's responsibility to incorporate their
code or diagnose them.
Fixes rdar://111101833.
If an accessor macro is placed on a computed property, then opts not to
produce a getter/setter, we would produce an error because the macro
didn't make the computed property... computed. Fix that; it's already
computed, and it's fine not to add accessors.
Fixes rdar://111586568.
The mangling of attached macro expansions based on the declaration to
which they are attached requires semantic information (specifically,
the interface type of that declaration) that caused cyclic
dependencies during type checking. Replace the mangling with a
less-complete mangling that only requires syntactic information from
the declaration, i.e., the name of the declaration to which the macro
was attached.
This eliminates reference cycles that occur with attached macros that
produce arbitrary names.
The macro tests were all using "REQUIRES: OS=macosx" as a proxy for
"have the Swift Swift parser". There was an existing feature for this,
but it was just checking whether the path was passed through. Fix that
to use the same variable as in CMake.
Also remove all extraneous `-I` and `-L` to the host libs in the target
invocations.
The fundamental problem here is that we don't know a priori whether an
accessor macro will convert a stored property into a computed one.
That can only be determined after macro expansion, which depends on
having a determined type for the property.
Implicit initialization of optional-typed values (e.g., "var
birthDate: Date?") adds the initializer when there is storage,
triggering the cycle. Introduce a very narrow fix that assumes that
properties that have an accessor macro on them do not have storage.
We probably want to enforce this, so that the "does this variable have
storage?" query can be made cheaper.
Extend the name mangling scheme for macro expansions to cover attached
macros, and use that scheme for the names of macro expansions buffers.
Finishes rdar://104038303, stabilizing file/buffer names for macro
expansion buffers.
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!
Accessor macros are attached macros (written with attribute syntax)
that can generate accessors for a property or subscript. Recognize
custom attributes that are accessor macros when written on a storage
declaration, and expand those macros.
This is very much a work in progress, and the result of the expansion
isn't yet parsed or wired into the AST.