-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Concurrency] Split up the non-Sendable
diagnostics and improve wording.
#75687
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
wording. Splitting up the diagnostic into separate diagnostics based on the reference kind is easier for me to read. The wording of the error message now puts the problem -- crossing an isolation boundary -- at the center of the message, and attempts to clarify how the value crosses an isolation boundary. E.g. for the witness diagnostics, the value crosses an isolation boundary when calling the witness through the protocol requirement in generic code. This change does not add any additional information to the diagnostics, but it'd be valuable to show both the source and destination isolation.
95fb0f0
to
933f8eb
Compare
Sendable
diagnostics and improve wording.
@swift-ci please smoke test |
@swift-ci please smoke test |
6d1c756
to
7dbec84
Compare
@swift-ci please smoke test |
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.
Looks like a good improvement, the case remains pretty confusing but this is better than before :)
Yeah agreed, I find the protocol witness and overriding cases particularly hard to explain in a one-line diagnostic. I suppose I should write educational notes for all of these! |
This change splits up the
Sendable
diagnostics for parameters, results, and property types. The old mega-diagnostic was difficult for me to piece together based on the various diagnostic arguments. Separate diagnostics makes it a bit easier to visualize what the resulting diagnostic will say for a given set of arguments.The wording of the error message now puts the problem -- crossing an isolation boundary -- at the center of the message instead of at the end, and attempts to clarify how the value crosses an isolation boundary. E.g. for the witness diagnostics, the value crosses an isolation boundary when calling the witness through the protocol requirement in generic code. I also eliminated some of the jargon like "implicitly asynchronous" because I don't think it's insightful for understanding this particular set of diagnostics.
For example:
Currently, the compiler produces the following error:
The above error is not ideal for 2 reasons:
With this change, the following error is produced:
This change (hopefully) clarifies that the problem occurs when you call the method through the nonisolated protocol requirement, because an isolation boundary is crossed when calling through to the underlying actor-isolated implementation.
This change does not add any additional information to the diagnostics, but it'd be valuable to show both the source and destination isolation.
Resolves: rdar://133215909