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.

Sign up for GitHub

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

Jump to bottom

Revamp borrowck treatment of closures #6801

Closed
nikomatsakis opened this issue May 29, 2013 · 5 comments · Fixed by #12158
Closed

Revamp borrowck treatment of closures #6801

nikomatsakis opened this issue May 29, 2013 · 5 comments · Fixed by #12158
Milestone
1.0

Comments

@nikomatsakis
Copy link
Contributor

As described in #2202 and this blog post, the borrow checker's treatment of closures needs to be changed. When a new closure is created, we should analyze the upvars that it accesses and create suitable borrows of those upvars that persist for the closure's lifetime. This is interrelated with #3696.
@nikomatsakis
Copy link
Contributor Author

Part of #2202

@nikomatsakis nikomatsakis mentioned this issue May 29, 2013
Closed
@goffrie goffrie mentioned this issue Jul 16, 2013
Closed
@metajack
Copy link
Contributor

triage bump. @nikomatsakis should this and the related bug be nominated? How does this interact with @fn being gone, etc?

@nikomatsakis nikomatsakis mentioned this issue Oct 15, 2013
Closed
@lilyball lilyball mentioned this issue Jan 29, 2014
Closed
@lilyball
Copy link
Contributor

If I understand this correctly, fixing this will significantly impact anyone who's using a closure in a destructor for RAII purposes (e.g. #11905). Nominating for backwards compat.

@pnkfelix
Copy link
Member

Accepted for 1.0, backcompat-lang.

@nikomatsakis
Copy link
Contributor Author

I've got a patch for this nearly ready to land. It definitely impacts some existing code. The patch is code complete but I've been working on writing up docs on the affected code patterns and how they must be updated.

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Feb 4, 2014
@nikomatsakis
WIP rust-lang#6801
b5cc693
This was referenced Feb 5, 2014
Closed
Closed
Closed
Merged
@bors bors closed this as completed in 0ac6e5a Feb 12, 2014
@nikomatsakis nikomatsakis mentioned this issue Feb 12, 2014
Closed
fhahn added a commit to fhahn/rust that referenced this issue Feb 12, 2014
@fhahn
Reenable some ignored test cases
195d8fd 
* src/test/run-pass/issue-3559.rs was fixed in rust-lang#4726
* src/test/compile-fail/borrowck-call-sendfn.rs was fixed in rust-lang#2978
* update src/test/compile-fail/issue-5500-1.rs to work with current Rust
* removed src/test/compile-fail/issue-5500.rs because it is tested in
    src/test/run-fail/issue-5500.rs
* src/test/compile-fail/view-items-at-top.rs fixed
* rust-lang#897 fixed
* compile-fail/issue-6762.rs issue was closed as dup of rust-lang#6801
* deleted compile-fail/issue-2074.rs because it became irelevant and is
  irrelevant rust-lang#2074, a test covering this was added in
  4f92f45
@nikomatsakis nikomatsakis mentioned this issue Feb 13, 2014
Closed
@pnkfelix pnkfelix mentioned this issue Nov 5, 2018
Closed
flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 11, 2021
@bors
Auto merge of rust-lang#6801 - Jarcho:manual_match_fix, r=phansch
ece3543 
Fix `manual_map` false positives

fixes: rust-lang#6795
fixes: rust-lang#6797
fixes: rust-lang#6811
fixes: rust-lang#6819

changelog: Fix false positives for `manual_map` when `return`, `break`, `continue`, `yield`, `await`, and partially moved values are used.
changelog: Don't expand macros in suggestions  for `manual_map`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
1.0
Development

Successfully merging a pull request may close this issue.

Issue 6801 borrowck closures nikomatsakis/rust
4 participants
@lilyball @metajack @nikomatsakis @pnkfelix