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.
Operator function witnesses are looked up globally. However, an additional, qualified lookup is warranted if the conforming type is declared in a local context.
Stop pretending that an optional requirement is immutable via the `StorageImplInfo` request.
This approach has lead astray the conformance checker and may have had a negative impact
on other code paths, and it doesn't work for imported declarations because they bypass the
request. Instead, use a forwarding `AbstractStorageDecl::isSettableInSwift` method
that special-cases optional requirements.
When the conformance checker and override checker detect a difference in a function type’s @Sendable attribute that varies in an illegal way, they now check if the protocol/base class was imported with an @preconcurrency import, and either limit the diagnostic or suggest adding @preconcurrency to the import as appropriate.
Completes rdar://91109455.
Every protocol gets an 'identity conformance' rule [P].[P] => [P].
A trivially-stated circularity is always redundant because of this
rule, and we diagnose circular inheritance elsewhere as a hard
error, so just add a special case to skip adding such a rule here
to avoid the useless warning on top of the existing error.
The previous warning "must be explicitly marked as 'any'" isn't clear if
you don't already know the feature, this new phrasing should make it
clearer by including the correct spelling of the type as an example.
Fixes rdar://90384448
If a requirement calls for a parameter's function type to be @Sendable, Swift will now permit a witness that does *not* make that parameter @Sendable. This is fine because @Sendable does not affect the calling convention and the witness may not need to exploit the opportunity to send the closure anywhere.
In other words, this code is now valid:
```
protocol P {
func fn(_: @Sendable () -> Void)
}
struct S: P {
func fn(_: () -> Void)
}
```
There's an edge case where this still isn't allowed when an associated type is @Sendable.
Ultimately this is to support the disambiguation of protocol requirements when printing stubs. This allows us to disambiguate the case where two modules declare a nominal type, and when that type appears in a protocol requirement. In such a case, we now fully qualify the types involved.
Fixing this also appears to now be consistently printing module qualification in many more places, hence the updates to the IDE/SourceKit tests.
rdar://72830118
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
When overriding a method or witnessing a requirement that comes from
Objective-C and has no actor annotation, allow the overriding method
or witness to specify a global actor (any global actor, but probably
almost always the main actor) without triggering the actor-isolation
errors one would normally get if both entities were written in Swift.
This opens up a hole in actor-isolation checking, because nothing
guarantees that code won't call these methods through the superclass
or protocol from the wrong actor. On the other hand, it's a very
convenient hole, because it allows us to state when we "know" that an
Objective-C framework will only call a method on (e.g.) the main
actor, and make that known to Swift to be enforced everywhere else in
Swift. If this is a good idea, it's plausible to introduce runtime
assertions of some form to tell the user when such an annotation is
wrong.
Review over a large number of APIs has found that most of the time, the
result type of an Objective-C completion handler method that becomes
"async throws" should be optional. Change the default behavior to
match this, and replace _Nullable_on_error with _Nullable_result to
capture the case where the result should be optional.
When concurrency is enabled, the same Objective-C method on a protocol can
be imported as two different protocol requirements, both of which have the
same selector. When performing conformance checking, only treat a
given @objc protocol requirement as "unsatisfied" by a conformance if
none of the requirements with the same Objective-C selector (+
instance/class designation) are satisfied.
