Skip to content

Make overloads and witnesses permit @Sendable variance + Make @preconcurrency import hide sendable variance #42273

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

Conversation

beccadax
Copy link
Contributor

@beccadax beccadax commented Apr 9, 2022

Cherry-picks two related PRs from main to release/5.7.

#42194:

For both overloaded methods and protocol witnesses, this PR:

  • Allows a non-@Sendable function type in the override/witness's parameters to match an @Sendable function type in the base/requirement.
  • Allows an @Sendable function type in the override/witness's results to match a non-@Sendable function type in the base/requirement.
  • Specially diagnoses any other difference in sendability, and reduces it to a warning in Swift 5 mode.

We'd like these warnings to also go away when @preconcurrency is used, but this seems like a reasonable stopping point.

Fixes rdar://91109455.

#42255:

When the conformance checker and override checker detect a difference in a function type’s @Sendable attribute that varies in an illegal way, they now check if the protocol/base class was imported with an @preconcurrency import, and either limit the diagnostic or suggest adding @preconcurrency to the import as appropriate.

Additionally, this PR makes it so we don't emit the remark recommending that @preconcurrency be added to an import if the type we're using has explicit sendability; after all, the author of the type has audited it and determined that any sendability problems in your code are not an error. Types in isConcurrencyChecked() modules are treated as always having explicit sendability for these purposes, since eventually we want to eliminate isConcurrencyChecked() and just serialize their public types as though they are explicitly non-sendable.

Completes rdar://91109455. Followup for #42194.

beccadax added 7 commits April 8, 2022 15:16
Specifically, an override can validly have a parameter type that is not `@Sendable` or a function type that is `@Sendable` even if that contradicts the base declaration. That’s becuase it’s always valid to provide a sendable function when one is not actually needed, but not vice versa.
It previously treated parameters and return types as the same, instead of properly handling variance.
If a type is explicitly non-Sendable, we don’t want to recommend softening errors with `@preconcurrency import` (even thought that would still work), because these probably represent *real* errors that you ought to fix. And at the extreme end of this, if a module is built with `-warn-concurrency` or `-swift-version 6`, *all* of its types should be treated as though they have explicit sendability, since we assume the entire module has been audited.

(Eventually, we plan to do this at module build time by actually serializing out unavailable conformances rather than by looking at the settings used to build the module, but we aren’t there quite yet.)

Implement this and test it by checking that the preconcurrency sendable tests never recommend adding `@preconcurrency` to an import of `StrictModule`, even when we do the same illegal things with it that cause that remark to be printed for `NonStrictModule`.
`diagnoseAsNonSendableBasedOn()` extracts just the “make a diagnostic sensitive to @preconcurrency import of this type” logic from `diagnoseNonSendableTypes()`. We need it because conformance and override checking should be sensitive to whether the conformed-to protocol/base class was imported with @preconcurrency or not, although this change is a pure refactoring.
When the conformance checker and override checker detect a difference in a function type’s @sendable attribute that varies in an illegal way, they now check if the protocol/base class was imported with an @preconcurrency import, and either limit the diagnostic or suggest adding @preconcurrency to the import as appropriate.

Completes rdar://91109455.
@beccadax beccadax requested a review from a team as a code owner April 9, 2022 00:14
@beccadax beccadax added the r5.7 label Apr 9, 2022
@beccadax
Copy link
Contributor Author

beccadax commented Apr 9, 2022

@swift-ci test

@beccadax beccadax merged commit c2eac8b into swiftlang:release/5.7 Apr 11, 2022
@AnthonyLatsis AnthonyLatsis added 🍒 release cherry pick Flag: Release branch cherry picks swift 5.7 labels Jan 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍒 release cherry pick Flag: Release branch cherry picks swift 5.7
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants