Skip to content

[ClangImporter] Allow @Sendable on more params #41737

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 1 commit into from
Mar 15, 2022

Conversation

beccadax
Copy link
Contributor

@beccadax beccadax commented Mar 8, 2022

When __attribute__((swift_attr(“https://github.com/sendable”))) is applied to a clang parameter Swift now attempts to make the type Sendable in a more comprehensive way than before:

  • If it is a function type, it adds @Sendable to it.
  • If it is a protocol composition type, it adds & Sendable to it.
  • If it is a class, protocol, or generic class, it inserts it into a protocol composition and adds & Sendable.
  • If it is a typealias, it may desugar it to a modified version of the underlying type.
  • In various other cases, it recurses into the children of the type.

This allows Objective-C methods and functions to require that their arguments have a Sendable type without specifying a particular type they must belong to.

Fixes rdar://87727549.

@beccadax beccadax requested review from kavon and DougGregor March 8, 2022 23:42
@beccadax
Copy link
Contributor Author

beccadax commented Mar 8, 2022

@swift-ci please smoke test

When `__attribute__((swift_attr(“@sendable”)))` is applied to a clang parameter Swift now attempts to make the type `Sendable` in a more comprehensive way than before:

* If it is a function type, it adds `@Sendable` to it.
* If it is a protocol composition type, it adds `& Sendable` to it.
* If it is a class, protocol, or generic class, it inserts it into a protocol composition and adds `& Sendable`.
* If it is a typealias, it *may* desugar it to a modified version of the underlying type.
* In various other cases, it recurses into the children of the type.

This allows Objective-C methods and functions to require that their arguments have a Sendable type without specifying a particular type they must belong to.

Fixes rdar://87727549.
@beccadax beccadax force-pushed the anything-can-be-sendable branch from 4f1f8d0 to 51e5408 Compare March 11, 2022 00:04
@beccadax
Copy link
Contributor Author

I've replaced the previous implementation with one that's much more rigorous and easy to reason about, at the cost of being much more verbose.

@beccadax
Copy link
Contributor Author

@swift-ci please smoke test

// CHECK-NEXT: func sendProtos(_ obj: LabellyProtocol & ObjCClub & Sendable)
// CHECK-NEXT: func sendAnyArray(_ array: [Sendable])
// CHECK-NEXT: func sendGeneric(_ generic: GenericObject<SendableClass> & Sendable)
// CHECK-NEXT: func sendPtr(_ val: UnsafeMutableRawPointer)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a warning about dropping the explicit sendability from the ObjC decl here and for the next function decl?

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 do emit some warnings through the experimental ClangImporter diagnostic infrastructure, but I don't want to rope that into these tests at its current stage of development.

@beccadax beccadax merged commit 7e473dc into swiftlang:main Mar 15, 2022
@beccadax beccadax deleted the anything-can-be-sendable branch March 15, 2022 22:10
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.

2 participants