Skip to content

[6.2][sema] Work around a double curry thunk actor isolation inference bug that is a knock on effect of ced96aa5cd653f834d2a8293ead8cf46649202cb. #82379

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 1 commit into from
Jun 21, 2025

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Jun 20, 2025

Explanation: There is currently a bug in TypeCheckConcurrency.cpp where we do not visit autoclosures. This causes us to never set the autoclosure's ActorIsolation field like all other closures. For a long time we were able to get away with this just by relying on the isolation of the decl context of the autoclosure... but with the introduction of nonisolated(nonsending), we found cases where the generated single curry autoclosure would necessarily be different than its decl context (e.x.: a synchronous outer curry thunk that is nonisolated that returns an inner curry thunk that is nonisolated(nonsending)). This problem caused us to hit asserts later in the compiler since the inner closure was actually nonisolated(nonsending), but we were thinking that it should have been concurrent.

To work around this problem, I changed the type checker in ced96aa to explicitly set the isolation of single curry thunk autoclosures when it generates them. The reason why we did this is that it made it so that we did not have to have a potential large source break in 6.2 by changing TypeCheckConcurrency.cpp to visit all autoclosures it has not been visiting.

This caused a follow on issue where since we were now inferring the inner autoclosure to have the correct isolation, in cases where we were creating a double curry thunk for an access to a global actor isolated field of a non-Sendable non-global actor isolated nominal type, we would have the outer curry thunk have unspecified isolation instead of main actor isolation. An example of this is the following:

class A {
  var block:  @MainActor () -> Void = {}
}

class B {
  let a = A()

  func d() {
    a.block = c // Error! Passing task isolated 'self' to @MainActor closure.
  }

  @MainActor
  func c() {}
}

This was unintentional. To work around this, this commit changes the type checker to explicitly set the double curry thunk isolation to the correct value when the type checker generates the double curry thunk in the same manner as it does for single curry thunks and validates that if we do set the value to something explicitly that it has the same value as the single curry thunk.

I also discovered in the process that I needed to add an ActorIsolationCrossing for these auto closures since as a result of not visiting them, we were not getting those set which caused us to no longer emit errors as we should in these cases. I did it /only/ for auto closures that have isolation set which can only be one of these double/single curry thunk auto closures since no other auto closures will have their isolation set.

Scope: Changes the actor isolation only of double curry thunks in the type checker and teaches the type checker how to detect if single or double curry thunks cause an actor isolation crossing to ensure we emit diagnostics.

Resolves: rdar://152522631

Main PR: #82375

Risk: Low. This only impacts code that uses double curry thunks and single curry thunks. Any other code that does not use curry thunks will not be impacted. So the impact is very localized on purpose.

Testing: Added compiler tests

Reviewer: @xedin

… that is a knock on effect of ced96aa.

Specifically, there is currently a bug in TypeCheckConcurrency.cpp where we do
not visit autoclosures. This causes us to never set the autoclosure's
ActorIsolation field like all other closures. For a long time we were able to
get away with this just by relying on the isolation of the decl context of the
autoclosure... but with the introduction of nonisolated(nonsending), we found
cases where the generated single curry autoclosure would necessarily be
different than its decl context (e.x.: a synchronous outer curry thunk that is
nonisolated that returns an inner curry thunk that is
nonisolated(nonsending)). This problem caused us to hit asserts later in the
compiler since the inner closure was actually nonisolated(nonsending), but we
were thinking that it should have been concurrent.

To work around this problem, I changed the type checker in
ced96aa to explicitly set the isolation of
single curry thunk autoclosures when it generates them. The reason why we did
this is that it made it so that we did not have to have a potential large source
break in 6.2 by changing TypeCheckConcurrency.cpp to visit all autoclosures it
has not been visiting.

This caused a follow on issue where since we were now inferring the inner
autoclosure to have the correct isolation, in cases where we were creating a
double curry thunk for an access to a global actor isolated field of a
non-Sendable non-global actor isolated nominal type, we would have the outer
curry thunk have unspecified isolation instead of main actor isolation. An
example of this is the following:

```swift
class A {
  var block:  @mainactor () -> Void = {}
}

class B {
  let a = A()

  func d() {
    a.block = c // Error! Passing task isolated 'self' to @mainactor closure.
  }

  @mainactor
  func c() {}
}
```

This was unintentional. To work around this, this commit changes the type
checker to explicitly set the double curry thunk isolation to the correct value
when the type checker generates the double curry thunk in the same manner as it
does for single curry thunks and validates that if we do set the value to
something explicitly that it has the same value as the single curry thunk.

rdar://152522631
(cherry picked from commit c28490b)
@gottesmm
Copy link
Contributor Author

@swift-ci test

@gottesmm gottesmm marked this pull request as ready for review June 20, 2025 18:09
@gottesmm gottesmm requested a review from a team as a code owner June 20, 2025 18:09
@gottesmm gottesmm enabled auto-merge June 20, 2025 19:43
@gottesmm gottesmm merged commit 25c2359 into swiftlang:release/6.2 Jun 21, 2025
5 checks passed
@gottesmm gottesmm deleted the release/6.2-152522631 branch June 26, 2025 19:42
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