[6.2][concurrency] Ensure that we treat closures that are nonisolated(nonsending) via their ActorIsolation as nonisolated(nonsending). #81363
+420
−79
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ending) via their ActorIsolation as nonisolated(nonsending). Some notes: 1. In most cases, I think we were getting lucky with this by just inferring the closure's isolation from its decl context. In the specific case that we were looking at here, this was not true since we are returning from an @Concurrent async function a nonisolated(nonsending) method that closes over self. This occurs since even when NonisolatedNonsendingByDefault we want to start importing objc async functions as nonisolated(nonsending). 2. I also discovered that in the ActorIsolationChecker we were not visiting the inner autoclosure meaning that we never set the ActorIsolation field on the closure. After some discussion with @xedin about potentially visiting the function in the ActorIsolationChecker, we came to the conclusion that this was likely to result in source stability changes. So we put in a targeted fix just for autoclosures in this specific case by setting their actor isolation in the type checker. 3. Beyond adding tests to objc_async_from_swift to make sure that when NonisolatedNonsendingByDefault is disabled we do the right thing, I noticed that we did not have any tests that actually tested the behavior around objc_async_from_swift when NonisolatedNonsendingByDefault is enabled. So I added the relevant test lines so we can be sure that we get correct behavior in such a case. rdar://150209093 (cherry picked from commit ced96aa)
|
@swift-ci test |
|
The failure is b/c I forgot to cherry-pick to 6.2 #81378. I am doing that now. |
When you wrote this, I just wanted to start the testing without adding the template since testing takes a while and I wanted to think about what I put into the template. No point in not starting the testing while I think about what I want to put in the template. |
|
@gottesmm I usually make PRs as drafts first in cases like that. |
hborla
approved these changes
May 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation: This PR fixes a bug where we were not assigning to SILFunctions from closures the actor isolation (and thus whether or not they have an implicit isolated parameter) from AbstractClosureExpr::actorIsolation. The result of this was that we would produce SILFunctionTypes that were inconsistent with the AnyFunctionType that they were lowered since AnyFunctionType's with nonisolated(nonsending) isolation would get SILFunctions without an implicit isolated parameter. This would then cause us to invoke SILGenPoly's transform infrastructure to crash.
In the process, @xedin and I also discovered that in the specific case we were looking at where one had two levels of auto closures, we were not visiting the inner auto closure in the ActorIsolationChecker meaning that we did not set AbstractClosureExpr::actorIsolation upon it. Since ensuring that we visited these auto closures in the ActorIsolationChecker would increase the surface area of the language that we were checking and result in potential source stable changes, we took a more targeted approach by recognizing the specific case where this happens in the type checker and just setting the appropriate actor isolation there.
Scope: Ensures that the inner auto closures in the test case in question have the appropriate actor isolation and that SILFunctions in general that are from closures respect the closure's actorIsolation if it is set.
Resolves: rdar://150209093
Main PR: #81338
Risk: Low. There are two things to consider: 1. By making it so that SILFunction/SILFunctionType respects the actor isolation of closures could change ABI in the case of nonisolated(nonsending) being lowered correctly. 2. Separately by ensuring in this specific inner/outer auto closure case that the inner auto closure has its actor isolation set correctly in the type checker instead of visiting in the ActorIsolationChecker, we keep the amount of risk caused by this change way done and avoid potentially source stability issues.
Testing: Added compiler tests
Reviewer: @xedin