-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SE-0461] Replace @execution(...)
with @concurrent
and nonisolated(nonsending)
#80668
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
swiftlang/swift-syntax#3047 |
swiftlang/swift-syntax#3047 |
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 have a question about the parsing logic in expression position, but otherwise this LGTM
// Try to parse '@' sign, 'inout' or 'nonisolated' as a attributed typerepr. | ||
if (Tok.isAny(tok::at_sign, tok::kw_inout) || | ||
Tok.isContextualKeyword("nonisolated")) { |
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.
Hmm, does this mean the following tries to parse as a nonisolated
type?
func nonisolated(_ x: Int) {}
nonisolated(0)
print("hello")
I noticed the swift-syntax PR doesn't include similar logic, should this just be removed?
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.
If I remove this condition C++ parser cannot parse - let _ = [nonisolated(nonsending) () async -> Void]()
, maybe there is a better way to do this I don't know about...
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 tightened the condition in canParseNonisolatedAsTypeModifier
and added your snippet. Rintaro pointed me to this spot initially for [nonisolated(nonsending) ...]()
support, but if there is a better way please let me know.
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 see! In that case, yes this is the correct place for the logic, I think you'll need similar logic in swift-syntax though, I suspect that will currently be parsing nonisolated(nonsending)
as a function call in that position (the way we model 'async'? 'throws'? '->'
in the parser is as a binary operator, and nonisolated(nonsending) ()
is a valid expression). I think it would be worth adding a couple more ASTGen tests to verify that's behaving correctly.
I tightened the condition in
canParseNonisolatedAsTypeModifier
and added your snippet
Thanks! In principle it's still source breaking if someone were passing an argument named nonsending
, but I doubt that'll ever come up in practice :)
@execution(...)
with @concurrent
and `nonisolated(nonsending)@execution(...)
with @concurrent
and nonisolated(nonsending)
9bde623
to
c61382f
Compare
We don't need a feature for this since the proposal was been accepted, that's why I've removed |
…ute` or `StringRef` It has been decided to split the attribute into `@concurrent` and `nonisolated(nonsending`. Adjusting diagnostics to accept the attribute makes the transition easier.
…(concurrent)` spelling
I thought the practice was to ship syntactic features as suppressible for a while for short-term textual interface compatibility. |
I don't think we make these backward compatibility guarantees (anymore?) based on conversation with @tshortli about |
These new/old attribute and modifier are not going to be present in old interface files unconditionally anyway. |
No, Anthony is right. There is a trailing window of previous development versions of the compiler that textual interfaces must remain compatible with. |
…execution(caller)`
Complete the transition from `@execution` to `@concurrent` and `nonisolated(nonsending)`
SE-0461 has been accepted and `@concurrent` and `nonisolated(nonsending)` can be make generally available now.
Accept it only if it's spelled `nonisolated(nonsending)` and nothing else to minimize any possible source compatibility impact.
…ure to match `@execution` attribute split
…ed(nonsending)` in swift interface files
b337552
to
734b1f1
Compare
For posterity: we discussed this offline and yes, we do need a feature flag here to indicate that new attributes are supported only by new compilers even though we have been inconsistent about this in the past. |
swiftlang/swift-syntax#3047 |
@swift-ci please test source compatibility |
swiftlang/swift-syntax#3047 |
swiftlang/swift-syntax#3047 |
@concurrent
declaration and type attributes to replace@execution(concurrent)
nonsending
modifier tononisolated
declaration modifiernonisolated(nonsending)
in type and expression contexts (modeled viaCallerIsolatedTypeRepr
)@execution(caller)
withnonisolated(nonsending)
modifier@execution
attribute throughout the codebaseExecutionAttribute
experimental flag