-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Adopt Sendable in the Task APIs #38866
Conversation
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
|
Welp, looks like I need to fix that compile error. |
e05f021
to
48e5414
Compare
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
| @@ -10,7 +10,7 @@ struct S1 { | |||
| var c: C2 | |||
| } | |||
|
|
|||
| enum E1 { | |||
| enum E1 { // expected-note{{add conformance of enum 'E1' to the 'Sendable' protocol}} | |||
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 message is a bit strange. We don’t add conformance of types to protocols. Might I suggest:
add conformance to the ‘Sendable’ protocol to the enum ‘E1’.
or even
add ‘Sendable’ conformance to the enum ‘E1’.
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.
We use the "consider" wording elsewhere, so I'm going to try out
consider making enum 'E1' conform to the 'Sendable' protocol
Rework Sendable checking to be completely based on "missing" conformances, so that we can individually diagnose missing Sendable conformances based on both the module in which the conformance check happened as well as where the type was declared. The basic rules here are to only diagnose if either the module where the non-Sendable type was declared or the module where it was checked was compiled with a mode that consistently diagnoses `Sendable`, either by virtue of being Swift 6 or because `-warn-concurrency` was provided on the command line. And have that diagnostic be an error in Swift 6 or warning in Swift 5.x. There is much tuning to be done here.
The notes that go along with Codable synthesis were being emitted before the actual "type does not conform" diagnostic, so they would be associated with a prior diagnostic... or dropped on the floor. Queue up the synthesis notes and emit them after the "type does not conform" diagnostic.
48e5414
to
42c0658
Compare
|
@swift-ci please smoke test |
…ormances. Extend the diagnostics for `Sendable` conformances to always diagnose missing `Sendable` conformances for nominal types that are within the same module. The intuition here is that if the type is in the same module, it can be updated and evaluated at the same time as code requiring the `Sendable` conformance is introduced. Another part of rdar://78269348.
This is part of SE-0311 that was not implemented. Fixes rdar://77441933.
|
@swift-ci please smoke test |
Rework
Sendablechecking to be completely based on "missing"conformances, so that we can individually diagnose missing
Sendableconformances based on both the module in which the conformance check
happened as well as where the type was declared. The basic rules here
are to only diagnose if the non-
Sendabletype either comes from thecurrent model or from a module that was compiled in a mode that
consistently diagnoses
Sendable. The latter is true for modulescompiled in Swift 6 mode or that provide
-warn-concurrencyonthe command line. This is tracked by rdar://78269348.
The diagnostics will be an error in Swift 6 or a warning in Swift 5.x.
Use this to adopt
Sendablein the Task APIs without breaking code,tracked by rdar://77441933.