Skip to content

[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

Merged
merged 14 commits into from
Apr 12, 2025

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Apr 9, 2025

  • Add @concurrent declaration and type attributes to replace @execution(concurrent)
  • Add new nonsending modifier to nonisolated declaration modifier
  • Make it possible to use nonisolated(nonsending) in type and expression contexts (modeled via CallerIsolatedTypeRepr)
  • Replace @execution(caller) with nonisolated(nonsending) modifier
  • Remove all of the references to @execution attribute throughout the codebase
  • Remove ExecutionAttribute experimental flag

@xedin
Copy link
Contributor Author

xedin commented Apr 9, 2025

swiftlang/swift-syntax#3047
@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Apr 10, 2025

swiftlang/swift-syntax#3047
@swift-ci please test

Copy link
Contributor

@hamishknight hamishknight left a 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

Comment on lines +545 to +547
// Try to parse '@' sign, 'inout' or 'nonisolated' as a attributed typerepr.
if (Tok.isAny(tok::at_sign, tok::kw_inout) ||
Tok.isContextualKeyword("nonisolated")) {
Copy link
Contributor

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?

Copy link
Contributor Author

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...

Copy link
Contributor Author

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.

Copy link
Contributor

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 :)

@xedin xedin changed the title [SE-0461] Replace @execution(...) with @concurrent and `nonisolated(nonsending) [SE-0461] Replace @execution(...) with @concurrent and nonisolated(nonsending) Apr 10, 2025
@xedin xedin force-pushed the se-0461-renamings branch from 9bde623 to c61382f Compare April 11, 2025 00:51
@xedin
Copy link
Contributor Author

xedin commented Apr 11, 2025

Curious: do we not need feature suppression for this new pair of attributes?

We don't need a feature for this since the proposal was been accepted, that's why I've removed ExecutionAttribute feature in this PR.

xedin added 5 commits April 11, 2025 12:08
@AnthonyLatsis
Copy link
Collaborator

We don't need a feature for this since the proposal was been accepted

I thought the practice was to ship syntactic features as suppressible for a while for short-term textual interface compatibility.

@xedin
Copy link
Contributor Author

xedin commented Apr 11, 2025

I don't think we make these backward compatibility guarantees (anymore?) based on conversation with @tshortli about -interface-compiler-version.

@xedin
Copy link
Contributor Author

xedin commented Apr 11, 2025

These new/old attribute and modifier are not going to be present in old interface files unconditionally anyway.

@tshortli
Copy link
Contributor

No, Anthony is right. There is a trailing window of previous development versions of the compiler that textual interfaces must remain compatible with.

xedin added 9 commits April 11, 2025 15:57
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.
@xedin xedin force-pushed the se-0461-renamings branch from b337552 to 734b1f1 Compare April 11, 2025 23:29
@xedin
Copy link
Contributor Author

xedin commented Apr 11, 2025

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.

@xedin
Copy link
Contributor Author

xedin commented Apr 11, 2025

swiftlang/swift-syntax#3047
@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented Apr 12, 2025

@swift-ci please test source compatibility

@xedin
Copy link
Contributor Author

xedin commented Apr 12, 2025

swiftlang/swift-syntax#3047
@swift-ci please test source compatibility

@xedin
Copy link
Contributor Author

xedin commented Apr 12, 2025

swiftlang/swift-syntax#3047
@swift-ci please test macOS platform

@xedin xedin merged commit 0caa9b5 into swiftlang:main Apr 12, 2025
7 checks passed
DataCorrupted added a commit to DataCorrupted/swift that referenced this pull request Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants