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-6148] SIL Representation of Closures #48703

Open
atrick opened this issue Oct 13, 2017 · 0 comments
Open

[SR-6148] SIL Representation of Closures #48703

atrick opened this issue Oct 13, 2017 · 0 comments
Labels
compiler The Swift compiler in itself new feature

Comments

@atrick
Copy link
Member

atrick commented Oct 13, 2017

Previous ID SR-6148
Radar None
Original Reporter @atrick
Type New Feature
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels New Feature
Assignee None
Priority Medium

md5: 24327f99caaf5af6e520b9c8bfb1f143

relates to:

Issue Description:

Once the Closure Capture ABI is implemented (https://bugs.swift.org/browse/SR-5441), there are some followup changes I would like to make to the SIL representation:

  • The SIL level partial_apply could take a single box for its context instead of one
    for each captured variable. All it does is bind the context to the function.
  • Unify SIL closure argument types: Let's do away with the strange
    SILGen "optimization" that sometimes converts nonescaping closure
    arguments to to @inout_aliasable. I don't think this accomplishes
    anything useful today but adds a lot of complexity.
  • Reliably distinguish noescaping from escaping SIL closure arguments
    as part of the SIL convention. This gives us a nice invariant that
    addresses are always statically exclusive. Nonescaping closures
    would always take arguments by address ($T*, $U*), and escaping
    closures would take arguments by box (${ var T }, ${ var U}).
@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
compiler The Swift compiler in itself new feature
Projects
None yet
Development

No branches or pull requests

1 participant