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

NLL: error from get-opts crate #47707

Closed
nikomatsakis opened this issue Jan 24, 2018 · 3 comments
Closed

NLL: error from get-opts crate #47707

nikomatsakis opened this issue Jan 24, 2018 · 3 comments
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

In #47596, @SimonSapin reported several NLL errors in dependencies of the servo crate. @lqd later minimized one of those errors into this example:

#![feature(nll)]

enum SplitWithinState { A, B }

fn each_split_within() {
    let mut state = SplitWithinState::A;
    let mut closure = || { state = SplitWithinState::A };
    if let SplitWithinState::A = state {
    }
    closure();
}

fn main() {}

which yields:

error[E0503]: cannot use `state` because it was mutably borrowed
 --> src/main.rs:8:12
  |
7 |     let mut closure = || { state = SplitWithinState::A };
  |                       ---------------------------------- borrow of `state` occurs here
8 |     if let SplitWithinState::A = state {
  |            ^^^^^^^^^^^^^^^^^^^ use of borrowed `state`

error: aborting due to previous error

That said, at first glance, this looks like it might be a bug fix -- the closure is assigning to state, so it has a mutable borrow, and the if let is testing it. Pretty sure this is #45045.

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-compiler-nll labels Jan 24, 2018
@nikomatsakis nikomatsakis added this to the NLL: Valid code works milestone Jan 24, 2018
@nikomatsakis
Copy link
Contributor Author

Going to close as duplicate of #45045 (and hence NLL is acting correctly)

@SimonSapin
Copy link
Contributor

Thanks for working out the details. It looks like this is already fixed in git upstream, filed rust-lang/getopts#60

@SimonSapin
Copy link
Contributor

… or not. rust-lang/getopts#61

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants