&mut self borrow conflicting with itself.

[leejunseok]

I don't know why this happens but rovar and XMPPwocky on IRC believed it to be a compiler bug.

struct A {
    a: i32
}

impl A {
    fn one(&mut self) -> &i32{
        self.a = 10;
        &self.a
    }
    fn two(&mut self) -> &i32 {
        loop {
            let k = self.one();
            if *k > 10i32 {
                return k;
            }
        }
    }
}

...gives the following error...

<anon>:12:21: 12:25 error: cannot borrow `*self` as mutable more than once at a time
<anon>:12             let k = self.one();
                              ^~~~
<anon>:12:21: 12:25 note: previous borrow of `*self` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `*self` until the borrow ends
<anon>:12             let k = self.one();
                              ^~~~
<anon>:17:6: 17:6 note: previous borrow ends here
<anon>:10     fn two(&mut self) -> &i32 {
...
<anon>:17     }
              ^
error: aborting due to previous error
playpen: application terminated with error code 101

Interestingly, if the second method is changed to...

    fn two(&mut self) -> &i32 {
        loop {
            let k = self.one();
            return k;
        }
    }

This will compile fine.

playpen: http://is.gd/mTkfw5

[gereeter]

I believe this is correct behavior. To see why, consider the code with explicit lifetime annotations:

struct A {
    a: i32
}

impl A {
    fn one<'a>(&'a mut self) -> &'a i32{
        self.a = 10;
        &self.a
    }
    fn two<'a>(&'a mut self) -> &'a i32 {
        loop {
            let k = self.one();
            if *k > 10i32 {
                return k;
            }
        }
    }
}

two needs to return a reference with the same lifetime as the mutable borrow given to it. However, since it gets its. This means that k must have lifetime 'a. However, for the returned value of one to have lifetime 'a, the input to one must also have lifetime 'a. This means that Rust is forced to not "reborrow" self and move it in to one. Since mutable references are linear, they can only be moved once, but the loop means that one may need to be called with the same mutable reference repeatedly.

The second example only works because Rust can see that the loop will only run once, so self will only be moved once.

[Gankra]

This looks like a non-lexical borrows issue. You can get similar behaviour without any loops at all:

struct Foo { data: Option<i32> }

fn main() {
    let mut x = Foo{data: Some(1)};

    foo(&mut x);
}

fn foo(x: &mut Foo) -> Option<&mut i32> {
    if let Some(y) = x.data.as_mut() {
        return Some(y);
    }

    println!("{:?}", x.data); 
    None
}

<anon>:14:22: 14:28 error: cannot borrow `x.data` as immutable because it is also borrowed as mutable
<anon>:14     println!("{:?}", x.data); 
                               ^~~~~~
note: in expansion of format_args!
<std macros>:2:43: 2:76 note: expansion site
<std macros>:1:1: 2:78 note: in expansion of println!
<anon>:14:5: 14:30 note: expansion site
<anon>:10:22: 10:28 note: previous borrow of `x.data` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `x.data` until the borrow ends
<anon>:10     if let Some(y) = x.data.as_mut() {
                               ^~~~~~
<anon>:16:2: 16:2 note: previous borrow ends here
<anon>:9 fn foo(x: &mut Foo) -> Option<&mut i32> {
...
<anon>:16 }
          ^
error: aborting due to previous error

Rustc can't "deal" with conditional borrowing returns.

[Gankra]

CC @pcwalton

[oli-obk]

I think the issue is actually that not the return value's mutability is used but the function argument's mutability.

The following code calls a mutating function that returns an immutable reference. After that I cannot take immutable references.

struct Foo (u8);

impl Foo {
    fn bar(&mut self) -> &u8 {
        self.0 += 1;
        &self.0
    }
}

fn main() {
    let mut x = Foo(42);
    let a = x.bar(); // note: borrow of `x` occurs here
    let b = x.0; // error: cannot use `x.0` because it was mutably borrowed
}

Playpen

I'm still running into this issue on the latest nightly. It appears that it treats returns as having a lifetime until the end of the function, even if the function without the return passes the borrow checker. This seems kind of odd, considering how the point of a return is to end the function early.

If you take a look at @gankro's example, it passes the borrow checker if you remove the return keyword, even though the resulting function won't work properly.

[Gankra]

This is blocked on non-lexical lifetimes, which is in turn blocked on MIR. Ideally this will be fixed by the end of 2016, but a fix won't land soon.

[oli-obk]

Some discussion on internals: https://internals.rust-lang.org/t/relaxing-the-borrow-checker-for-fn-mut-self-t/3256

[aidanhs]

Non lexical borrows feature discussion: rust-lang/rfcs#811

[Mark-Simulacrum]

So reading the internals thread makes me feel like this isn't fixable (even with NLL). Can someone confirm? (@eddyb?)

[eddyb]

cc @rust-lang/lang

[nikomatsakis]

This is indeed NLL and, if I'm not mistaken, it would be fixed by the various proposals that I have made. This roughly corresponds to "problem case #3" from my first blog post. The basic idea (in terms of the formulation from the latest blog post) of why it would work is that the subtyping the borrow would only be required to extend until the end of 'a in the branch of the if that causes a return.

[krdln]

@nikomatsakis Could you please elaborate more on how NLL interacts with this issue? In my mental model of &mut references, they can be passed either by move or reborrow, and the problem in this issue is that the return requires the move mode, and the re-use of self afterwards requires reborrow. In my understanding, the new reborrowed &mut reference's lifetime is limited by the lifetime of the variable holding the &mut-reference – in this case, self variable, thus it's limited by the function's body, thus it cannot extend outside the function call. Are the NLL going to change that limitation of reborrows (or maybe there is no such limitation)?

Also I am wondering if fixing this issue is something inherently tied to NLL or is it maybe orthogonal? If it's the latter, maybe it's worth landing a fix before NLL?

Also, if NLL are going to fix this issue, does that mean that under NLL you'll never have to manually choose between a move and reborrow?

[osa1]

Is this going to be fixed any time soon?