[6.0] Change behavior of implied 'Sendable' conformance #74914
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
A conditional conformance to a protocol does not usually imply
a conformance to the protocol's inherited protocols, because
we have no way to guess what the conditional requirements
should be.
A carveout was added for 'Sendable', so that protocols could
inherit from 'Sendable' retroactively. However, the 'Sendable'
conformance would become conditional, which causes us to
reject a _second_ conditional conformance to such a protocol:
struct G<T> {}
protocol P: Sendable {}
protocol Q: Sendable {}
extension G: P where T: P {}
extension G: Q where T: Q {}
To make this work, tweak the code so that an implied conformance
has the same generic signature as the conforming type, that is,
we force it to be unconditional.
Fixes rdar://122754849
Fixes swiftlang#71544
You can't do this anymore:
struct G<T> {}
protocol P: Sendable {}
extension G: P where T: P {}
Fixes rdar://95695543.
…sion instead of -strict-concurrency Also add some comments to explain what in the world is going on with the new checks.
slavapestov
force-pushed
the
fix-impliedsendable-conformance-6.0
branch
from
4654142 to
31074f3
Compare
DougGregor
approved these changes
Jul 3, 2024
|
@swift-ci Please test |
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.
6.0 cherry-pick of #74908
Description: If a type conditionally conforms to two protocols that both adopt Sendable retroactively, we would attempt to synthesize two conditional conformances to Sendable with incompatible requirements. Instead, change it so that the implied Sendable conformance is unconditional in
-swift-version 5mode, and ban it outright in-swift-version 6.Origination: This is a long-standing issue with conditional conformances, where the original Sendable carveout never quite worked right.
Reviewed by: @DougGregor
Risk: Low. We might now diagnose a non-Sendable stored property in more cases, because the Sendable conformance is unconditional, but in
-swift-version 5this was a warning, so this should not be a source break. In-swift-version 6, the new behavior is source breaking because the implied Sendable conformance must be declared explicitly. However, this matches the intent of-swift-version 6.Radar: rdar://95695543, rdar://122754849.