Skip to content

[region-isolation] A few improvements + If a value is dynamically actor isolated, do not consider it transferred if the transfer statically was to that same actor isolation. #72583

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 7 commits into from
Mar 26, 2024

Conversation

gottesmm
Copy link
Contributor

@gottesmm gottesmm commented Mar 26, 2024

This PR contains a few different changes that build on each other to solve rdar://123474616 (the title problem of the radar). Specifically (ignoring a test fix change):

  1. b19081d. I have been meaning to make this change for some time. It just makes it easier to read the debug output to check if a specific value has the wrong isolation kind.
  2. 5e58aa6. While doing work for the main piece of work here, I noticed that when dealing with values captured in isolated closures, we were always saying that they are task isolated... which is wrong! Instead I needed to use the dynamic isolation information of the value at the transfer point provided by the dynamic isolation tracking infrastructure I added recently. rdar://125372336
  3. d0d2f2d. After doing that, I realized that the previous diagnostic was a diagnostic that I missed when I was converting diagnostics to have named forms. In this commit I did that taking advantage again of the dynamic isolation information. rdar://125372790.
  4. 8243b5c. This is the main meat of the PR. In this commit I make it so that if a value is actor isolated and is passed to a closure isolated to the same actor, we do not treat the passing to the closure as a transfer. We still have a require though. rdar://123474616.
  5. e36aab6. In this PR, I finish by making it so that we ignore use after transfer if we can prove that the use is actor isolated to the same actor as the place we transferred the value or if the use doesn't make any isolation assumptions but is running in a context that has the same actor isolation as the place we transfer the parameter, then we squelch the error.

…the full value state of the value instead of just the representative.

Just makes it easier to debug.
…d of "GlobalActor" for its custom global actor.

Just makes it easier to read.

NFC.
… of a never transferrable value, use the dynamic isolation. Do not assume it is task isolated.

rdar://125372336
… capture by an isolated closure diagnostic to be a named diagnostic.

rdar://125372790
…onsider it transferred if the transfer statically was to that same actor isolation.

This issue can come up when a value is initially statically disconnected, but
after we performed dataflow, we discovered that it was actually actor isolated
at the transfer point, implying that we are not actually transferring.

Example:

```swift
@mainactor func testGlobalAndGlobalIsolatedPartialApplyMatch2() {
  var ns = (NonSendableKlass(), NonSendableKlass())
  // Regions: (ns.0, ns.1), {(mainActorIsolatedGlobal), @mainactor}

  ns.0 = mainActorIsolatedGlobal
  // Regions: {(ns.0, ns.1, mainActorIsolatedGlobal), @mainactor}

  // This is not a transfer since ns is already main actor isolated.
  let _ = { @mainactor in
    print(ns)
  }

  useValue(ns)
}
```

To do this, I also added to SILFunction an actor isolation that SILGen puts on
the SILFunction during pre function visitation. We don't print it or serialize
it for now.

rdar://123474616
…ely the same isolation as the transfer inst.

To be more specific this means that either:

1. The use is actually isolated to the same actor. This could mean that the
use is global actor isolated to the same function.

2. The use is nonisolated but is executing within a function that is globally
isolated to the same isolation domain.

rdar://123474616
@gottesmm
Copy link
Contributor Author

@swift-ci smoke test

@gottesmm gottesmm enabled auto-merge March 26, 2024 07:07
@gottesmm
Copy link
Contributor Author

Forgot to disable error squelching in the unit tests which do not have access to the functionality

@gottesmm
Copy link
Contributor Author

@swift-ci smoke test

To squelch errors, we need access to functionality not available in the
unittests. The unittests do not require this functionality anyways, so just
disable squelching during the unittests.
@gottesmm
Copy link
Contributor Author

@swift-ci smoke test

@gottesmm gottesmm merged commit 8679b62 into swiftlang:main Mar 26, 2024
@gottesmm gottesmm deleted the more-fixes branch March 26, 2024 20:05
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.

1 participant