[6.0][region-isolation] Improve the error we emit for closure literals captured as a sending parameter.

[gottesmm]

Explanation: [6.0][region-isolation] Improve the error we emit for closure literals captured as a sending parameter.

Before region isolation and sending closures, Task.init took an @Sendable closure. If non-Sendable state was captured in the closure, we emitted a specific error on the captured value. This provided a discoverable bread crumb that the user could use to trace back what the exact problem was (noting that takeSendableClosure is where Task.init) would be:

tmp.swift:8:11: error: capture of 'x' with non-sendable type 'NonSendableKlass' in a `@Sendable` closure
 1 | 
 2 | class NonSendableKlass {}
   |       `- note: class 'NonSendableKlass' does not conform to the 'Sendable' protocol
 3 | 
 4 | func takeSendableClosure(_ x: @Sendable () -> ()) {}
   :
 6 | func foo(_ x: NonSendableKlass) {
 7 |   takeSendableClosure {
 8 |     print(x)
   |           `- error: capture of 'x' with non-sendable type 'NonSendableKlass' in a `@Sendable` closure
 9 |   }
10 | }

When we introduced region isolation and changed Task.init to take a sending closure, we regressed this behavior unintentionally. With region isolation and a sending closure the above error is emitted instead:

tmp.swift:5:3: error: task-isolated value of type '() async -> ()' passed as a strongly transferred parameter; later accesses could race
3 | 
4 | func foo(_ x: NonSendableKlass) async {
5 |   Task {
  |   `- error: task-isolated value of type '() async -> ()' passed as a strongly transferred parameter; later accesses could race
6 |     print(x)
7 |   }

this doesn't provide a breadcrumb for the user to work back from anymore. With this change, we ameliorate this situation by introducing a special diagnostic that ensures that the user always has a breadcrumb. With this change, we now get the following error message:

tmp.swift:5:8: error: passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure
3 | 
4 | func foo(_ x: NonSendableKlass) {
5 |   Task {
  |        `- error: passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure
6 |     print(x)
  |           `- note: closure captures 'x' which is accessible to code in the current task
7 |   }
8 | }

Radars:

• rdar://133798044

Original PRs:

• [region-isolation] Improve the error we emit for closure literals captured as a sending parameter. #75873

Risk: Low. This does not impact where we emit errors... it just changes the actual error that we are emitting. Also, I pattern matched specifically against closure literals passed as a sending parameter, so if I did introduce a problem, it will occur narrowly just in this case (a case that we were already going to reject anyways). So the potential fallout is not large. Also this only applies to swift 6 and swift 5 + strict-concurrency.

[atrick]

LGTM

[gottesmm]

@swift-ci test

[gottesmm]

@swift-ci test macOS platform