[6.0] Fix function subtyping rules for sending #74428
Merged
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
…witnessed by a function without a sending result. This is important since the witness is not promising to return a disconnected value and the caller of the requirement is going to accept that. rdar://127675288 (cherry picked from commit 1c9b178)
rdar://127675288 (cherry picked from commit 3c166b5)
… computeFailureTypeWitness. The problem happens when a type conforms to AsyncIterator.next when next in the protocol returns its value as sending, but the witness does not have sending. This results in the function subtyping rules rejecting the witness... but we still leave in the witness as a nullptr... so we need to handle it here. rdar://129300953 (cherry picked from commit 83bcf23)
…testing typecheck errors. (cherry picked from commit ba6c8af)
…rs and results. I found this while writing tests for the earlier part of this work. Since this is also type checking work, I am just folding this work into that work. (cherry picked from commit 2ac874e)
The previous commit fixed things like:
```swift
let x: () -> sending String = { "" }
```
This commit fixes this test case:
```swift
let x = { () -> sending String in "" }
```
(cherry picked from commit 81100ad)
(cherry picked from commit a451fe6)
…when not in swift 6. This will ensure that we do not break anyone who has adopted APIs like CheckedContinuation.resume that now have sending parameters. An example of where this can come up is shown by the ProcessType in SwiftToolsCore: ```swift @available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *) @discardableResult public func waitUntilExit() async throws -> ProcessResult { try await withCheckedThrowingContinuation { continuation in DispatchQueue.processConcurrent.async { self.waitUntilExit(continuation.resume(with:)) } } } ``` This fails to compile since self.waitUntilExit doesn't expect a function that takes a sending parameter. We want to give people time to fix such issues. (cherry picked from commit 16d0194)
|
Original: #74129 |
|
@swift-ci test |
For now, just turn off the error in swift 5 mode. I wanted to make this an error but right now I do not have all of the time to do it so this is good in the short term so that people can adopt sending on protocols without breaking people using their framework in executables still compiling in swift 5. (cherry picked from commit c8d9e18)
|
@swift-ci test |
hborla
approved these changes
Jun 17, 2024
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 function sub typing rules for sending. Specifically:
Radars:
Original PRs:
Risk: Low. This is improving the compiler since these concurrency holes would result in other weird crashes.
Testing: Added exhaustive tests to the test suite.
Reviewer: N/A