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.
The standard library's enqueue() does not play by the same rules -- we
provide "deprecated" implementations in order to remain source/binary
compatible, and showing warnings about this when users make mistake will
only be misleading.
Temporarily cherry-pick Swift 5.9’s behavior of turning @objcImplementation errors into warnings to 5.10 until we fix the last few bugs in these diagnostics.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
This is a very large diagnostic, where the second half is mostly aimed
at macro authors rather than clients. Cut it down to the base
diagnostic.
Resolves rdar://113646544.
The reason why we are doing this is that this combination of read/set forces the
compiler to emit a copy if we want to emit a modify operation.
The reason why we are forced to emit such a copy is that:
1. _read provides a guaranteed value in memory
2. performing a modify requires an owned value in memory.
This together implies that the only way we can do this is to copy from the _read
into temporary memory. But we have a noncopyable type so we can't do this.
rdar://112915525
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.
This attribute can be attached to a noncopyable struct to specify that its
storage is raw, meaning the type definition is (with some limitations)
able to do as it pleases with the storage. This provides a basis for
implementing types for things like atomics, locks, and data structures
that use inline storage to store conditionally-initialized values.
The example in `test/Prototypes/UnfairLock.swift` demonstrates the use
of a raw layout type to wrap Darwin's `os_unfair_lock` APIs, allowing
a lock value to be stored inside of classes or other types without
needing a separate allocation, and using the borrow model to enforce
safe access to lock-guarded storage.
