-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Concurrency] Fix preconcurrency downgrade behavior for Sendable
closures and generic requirements.
#77459
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
@Sendable
closures.
@swift-ci please smoke test |
ed4e7d5
to
47089ed
Compare
…ures. Sendable violations inside `@preconcurrency @Sendable` closures should be suppressed in minimal checking, and diagnosed as warnings under complete checking, including the Swift 6 language mode.
to warnings even in Swift 6.
47089ed
to
a31a9d3
Compare
@swift-ci please smoke test |
…lures to warnings in Swift 6 mode.
@swift-ci please smoke test |
@swift-ci please test source compatibility |
@Sendable
closures.Sendable
closures and generic requirements.
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 all looks safe, and will downgrade a number of errors to warnings based on @preconcurrency
. Thank you!
// FIXME: contextRequiresStrictConcurrencyChecking is called from | ||
// within the constraint system, but closures are only set to be isolated | ||
// by preconcurrency in solution application because it's dependent on | ||
// overload resolution. The constraint system either needs to check its | ||
// own state on the current path, or not make type inference decisions based | ||
// on concurrency checking level. | ||
if (isolatedByPreconcurrency(explicitClosure)) { |
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 is why isolatedByPreconcurrency is a closure that's passed in, right?
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.
Yes, and it looks like ClosureIsolatedByPreconcurrency
(used by constraint system calls) does check the constraint system state, but I ran into a case while debugging where this line of code returned an unexpected result mid constraint solving. It didn't seem to be causing any issues for the preconcurrency downgrade behavior, so I left this comment for myself to figure out what happened there after I land this.
@swift-ci build toolchain |
@swift-ci build toolchain macOS platform |
Hmm, this toolchain did not appear to work. Building the current
This is the |
erasure expressions for arguments to `@preconcurrency` functions in Swift 6 mode.
@swift-ci build toolchain |
@swift-ci please smoke test |
…rmances to `Sendable`.
@swift-ci build toolchain |
@swift-ci please smoke test |
Sendable violations inside
@preconcurrency @Sendable
closures should be suppressed in minimal checking, and diagnosed as warnings under complete checking, including the Swift 6 language mode. This change fixes an issue where warnings were still produced in minimal checking, and errors were still produced under-swift-version 6
, which means that libraries cannot stage in newSendable
annotations if their clients have already migrated to Swift 6.The preconcurrency downgrade infrastructure is currently pretty difficult to follow, because the information is passed through
SendableCheckContext
throughout thediagnoseNonSendableTypes
APIs, and there are different code paths for@preconcurrency
on nominal declarations versus import statements. This PR does not attempt to clean any of this code up, because I'd like to cherry pick the bug fix torelease/6.0
. I'll look at clarifying this code in a follow up change.This change also downgrades
Sendable
requirement failures when the requirement is on a@preconcurrency
declaration. However, the change in this PR is not sufficient for requirement inference, e.g.A case like the above requires more careful handling.
@preconcurrency
can't simply be inferred onf
, because that would break ABI by strippingU: Sendable
from the generic signature.@preconcurrency
may need to apply per requirement in order to maintain source compatibility without breaking ABI.Resolves: rdar://138535438, rdar://139234188, #76652