Skip to content
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

[SR-12820] No way to avoid ARC traffic for closures known not to escape #55266

Open
dabrahams opened this issue May 15, 2020 · 0 comments
Open
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself standard library Area: Standard library umbrella

Comments

@dabrahams
Copy link
Collaborator

Previous ID SR-12820
Radar None
Original Reporter @dabrahams
Type Bug
Additional Detail from JIRA
Votes 1
Component/s Compiler, Standard Library
Labels Bug
Assignee None
Priority Medium

md5: 264446cc88dffb0e861de599f03d29a2

Issue Description:

Consider a parallel `forEach`. We know the closure doesn't escape the call, but it needs to be copied to all threads. Even if we `unsafeBitCast` the type of the closure away, there's no way to call it without inducing a retain/release pair, as you can see here: https://swift.godbolt.org/z/igFqV9

Of course I realize the type aliasing is probably illegal, but it serves to illustrate the point. The function pointer in the closure uses a calling convention that matches neither @convention(c) nor @convention(thin), so there's no way to invoke it and manually pass the context pointer without generating ARC traffic. We really need some kind of callable UnmanagedFunction<F> type or @convention(rawSwift) to represent the raw function pointer in the closure.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

1 participant