Skip to content

[6.2][Concurrency] Hashable funcs should be inlinable for AsyncStream #81127

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

Open
wants to merge 2 commits into
base: release/6.2
Choose a base branch
from

Conversation

ktoso
Copy link
Contributor

@ktoso ktoso commented Apr 28, 2025

Small review followup for #81064

The impls should be @inlinable.

Original PR: #81126
Radar: rdar://149914179

@ktoso ktoso requested a review from a team as a code owner April 28, 2025 02:04
@ktoso ktoso requested a review from DougGregor April 28, 2025 02:04
@ktoso ktoso changed the title [Concurrency] Hashable funcs should be inlinable for AsyncStream [6.2][Concurrency] Hashable funcs should be inlinable for AsyncStream Apr 28, 2025
@ktoso ktoso force-pushed the pick-wip-inlinable-for-hashable-asyncstream branch from 5442de0 to 5a1e66f Compare April 28, 2025 03:29
@ktoso
Copy link
Contributor Author

ktoso commented Apr 28, 2025

@swift-ci please test

@ktoso
Copy link
Contributor Author

ktoso commented Apr 28, 2025

@swift-ci please test

@ktoso ktoso force-pushed the pick-wip-inlinable-for-hashable-asyncstream branch from 5a1e66f to 1cfef25 Compare April 28, 2025 07:18
@ktoso
Copy link
Contributor Author

ktoso commented Apr 28, 2025

@swift-ci please test

Comment on lines +487 to +489
@inlinable
@available(SwiftStdlib 6.2, *)
@inlinable
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: looks like there are double annotations for some reason – is that intentional?

@@ -55,6 +55,7 @@ func _unlock(_ ptr: UnsafeRawPointer)
@available(SwiftStdlib 5.1, *)
extension AsyncStream {
@safe
@usableFromInline
Copy link
Contributor

Choose a reason for hiding this comment

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

tangential question regarding this change – i've for some time wondered if the internal storage for these types could in some way be unified into something like _Storage<Element, E: Error> since they have so much duplication. does this change make that idea less feasible?

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.

3 participants