-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Make @preconcurrency import hide sendable variance #42255
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
Make @preconcurrency import hide sendable variance #42255
Conversation
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`.
@swift-ci please smoke test |
lib/Sema/TypeCheckConcurrency.h
Outdated
/// | ||
/// \returns \c true if any errors were produced, \c false if no diagnostics or | ||
/// only warnings and notes were produced. | ||
bool diagnoseAsNonSendableBasedOn( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could probably use a better name—suggestions welcome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
diagnoseAsNonSendableFromContext
? It's not that much better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up with diagnoseSendabilityErrorBasedOn()
, which is at least more vague about the kind of error we're emitting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great!
lib/Sema/TypeCheckConcurrency.h
Outdated
/// | ||
/// \returns \c true if any errors were produced, \c false if no diagnostics or | ||
/// only warnings and notes were produced. | ||
bool diagnoseAsNonSendableBasedOn( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
diagnoseAsNonSendableFromContext
? It's not that much better.
`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.
9625e48
to
ecdd42f
Compare
@swift-ci smoke test and merge |
@swift-ci please smoke test linux platform |
@swift-ci smoke test macOS platform |
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 inisConcurrencyChecked()
modules are treated as always having explicit sendability for these purposes, since eventually we want to eliminateisConcurrencyChecked()
and just serialize their public types as though they are explicitly non-sendable.Completes rdar://91109455. Followup for #42194.