Super-level sendable checking for function parameters in overrides and conformances #66640
Conversation
JTurcotti
requested review from
AnthonyLatsis,
hborla,
slavapestov and
xedin
as code owners
| // requirement parameters not witness parameters | ||
| @available(SwiftStdlib 5.1, *) | ||
| actor A : P { | ||
| func foo(x : () -> ()) -> () {} |
There was a problem hiding this comment.
the lack of a diagnostic here is 1 of the 2 features added by this PR
| // of superclass parameters not subclass parameters | ||
| @available(SwiftStdlib 5.1, *) | ||
| class Sub : Super { | ||
| override nonisolated func foo<T>(x: T) async {} |
There was a problem hiding this comment.
the lack of a diagnostic here is 1 of the 2 features added by this PR
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
| // make sure conformance to protocols checks sendability of | ||
| // requirement parameters not witness parameters | ||
| @available(SwiftStdlib 5.1, *) | ||
| actor A : P { |
There was a problem hiding this comment.
nitpick: funny formatting here, the leading spaces
| protocol P { | ||
| func foo (x : @Sendable () -> ()) async -> () | ||
|
|
||
| func bar(x : () -> ()) async -> () |
There was a problem hiding this comment.
I actually wonder if the warning can be emitted always already when we see such func in a protocol on an async func? Since an async func, in a class/struct will execute on global pool, and on an actor "on the actor", so in any case this will cross an async boundary so needs to be sendable always, doesn't it?
There was a problem hiding this comment.
methods of classes can also be async, so this protocol could also be used to allow one class's async method to call another class's async method without crossing an isolation boundary. This I believe is a valid use case for a protocol requirement for an async method without sendable parameters.
| return 0 | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
tiny nit, missing newline at the end of the file.
JTurcotti
force-pushed
the
protocol-variance
branch
from
d84d80a to
f9a2b00
Compare
JTurcotti
force-pushed
the
protocol-variance
branch
2 times, most recently
from
d866f09 to
5b5e654
Compare
|
@swift-ci please smoke test |
JTurcotti
force-pushed
the
protocol-variance
branch
2 times, most recently
from
31cde0c to
1be4155
Compare
…he past, both the results and parameters of overriding (resp. conforming) functions were checked for Sendability. This is overly restrictive. For safety, the parameters of the overridden (resp. requiring) function should be checked for Sendability and the results of the overriding (resp. conforming) should be checked. This commit implements that change.
JTurcotti
force-pushed
the
protocol-variance
branch
from
1be4155 to
eb78da2
Compare
|
@swift-ci smoke test |
|
@swift-ci please smoke test |
Sendable checking for overrides and protocol conformances ensures that if the override crosses an isolation domain the parameters and results of the overriding method are sendable. This is technically too strict, as only the parameters of the overridden method need be sendable. This PR fixes this for override and conformance checks by splitting the sendable checking to check Sensibility of parameters of the overridden method, and results of the overriding method.
The test
sendable_checking.swiftensures that new code now typechecks such as:for overrides, and
for conformances.
note: this PR supplants #66605.