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.
