Skip to content

[6.0][region-isolation] Treat async let as a isolation inference boundary closure and fix diagnostics due to change. #75080

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 9, 2024

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Jul 8, 2024

Explanation: Previously, we would infer async let's auto closure isolation from its DeclContext. I noticed this due to cases where async let was getting an actor instance's isolation. That is incorrect since an async let autoclosure should always
be nonisolated + sending.

The diagnostic change that I mentioned in the header is that we were emitting
unfortunate "sending task or actor isolated could result in races" error. I
eliminated this by adding a new diagnostic for transfer non transferrable errors
happening in autoclosures. So now we emit this:

  func asyncLetInferAsNonIsolated<T : Actor>(
    isolation actor: isolated T
  ) async throws {
    async let subTask: Void = {
      await useValueAsyncNoReturnWithInstance(self, actor)
      // expected-warning @-1:47 {{sending 'self' risks causing data races}}
      // expected-note @-2 {{sending 'actor'-isolated 'self' into async let risks causing data races between nonisolated and 'actor'-isolated uses}}
    }()
    await subTask

Radars:

  • rdar://130151318
  • rdar://127477165

Original PRs:

Risk: Low. This only affects auto closures that work with async lets. We definitely want this since this could potentially affect source stability. That being said since it only should affect diagnostics this is safe to take (the task the async let runs is defined by other parts of the compiler, not by this code).
Testing: Added/Ran tests
Reviewer: N/A

gottesmm added 2 commits July 8, 2024 14:49
This is triggered by the test case in the next commit. The problem is anonymous
closures can be passed here and they do not have a ValueDecl so there isn't a
decl for us to use.

(cherry picked from commit 57392b1)
…closure and fix diagnostics due to change.

Otherwise, we will assume that an async let autoclosure infers isolation from
its DeclContext... which we do not want. An async let autoclosure should always
be nonisolated + sending.

The diagnostic change that I mentioned in the header is that we were emitting
unfortunate "sending task or actor isolated could result in races" error. I
eliminated this by adding a new diagnostic for transfer non transferrable errors
happening in autoclosures. So now we emit this:

```swift
  func asyncLetInferAsNonIsolated<T : Actor>(
    isolation actor: isolated T
  ) async throws {
    async let subTask: Void = {
      await useValueAsyncNoReturnWithInstance(self, actor)
      // expected-warning @-1:47 {{sending 'self' risks causing data races}}
      // expected-note @-2 {{sending 'actor'-isolated 'self' into async let risks causing data races between nonisolated and 'actor'-isolated uses}}
    }()
    await subTask
```

I also noticed that we did not have enough test cases for autoclosures in
general so I also added a bunch of tests just so we can see what the current
behavior is. I think there are a few issues therein (I believe some may have
been reported due to '??').

rdar://130151318
(cherry picked from commit 03b26fd)
@gottesmm gottesmm requested a review from a team as a code owner July 8, 2024 21:54
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 8, 2024

@swift-ci test

@gottesmm gottesmm requested review from DougGregor and hborla July 8, 2024 21:55
@gottesmm gottesmm enabled auto-merge July 8, 2024 23:13
@gottesmm
Copy link
Contributor Author

gottesmm commented Jul 8, 2024

FYI, I found another radar that this fixes. I added it to the PR description.

@gottesmm gottesmm merged commit 03a9292 into swiftlang:release/6.0 Jul 9, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants