Give a better error message for shared borrow treated as unique for purposes of lifetimes

[bonsairobo]

I tried this code:

#[derive(Default)]
struct Foo { i: i32, j: i32 }

impl Foo {
    fn modify_and_borrow(&mut self) -> &i32 { self.j += 1; &self.i }
}

fn main() {
    let mut foo = Foo::default();
    let mut refs = Vec::new();
    for _ in 0..2 {
        refs.push(foo.modify_and_borrow());
    }
}

I expected to see this happen:

The error should say something like, "cannot borrow foo as mutable while it is already borrowed as immutable."

Instead, this happened:

error[E0499]: cannot borrow `foo` as mutable more than once at a time
  --> src/main.rs:12:19
   |
12 |         refs.push(foo.modify_and_borrow());
   |                   ^^^ mutable borrow starts here in previous iteration of loop

Meta

Playground link:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a6450c7200878a52ff8bf4466cb09f5f

[jonas-schievink]

modify_and_borrow does a mutable borrow though, so the message looks correct to me

[bonsairobo]

@jonas-schievink But it doesn't mutably borrow "more than once at a time" right? The mutable borrow gets dropped before the end of each iteration.

[jonas-schievink]

The returned &i32 mutably borrows self and is pushed onto refs

[bonsairobo]

Hmm that doesn't make sense to me. How is &i32 a mutable borrow of self?

[jyn514]

https://doc.rust-lang.org/nomicon/lifetime-mismatch.html#limits-of-lifetimes

[bonsairobo]

@jyn514 Thank you! I didn't realize that the lifetime of the mutable borrow was being extended to the same lifetime as the immutable borrows.

I guess that makes sense, because locally inside of modify_and_borrow, the compiler just sees that you've been given a reference to self, so it must return a reference with the same lifetime. If it had the global knowledge that foo lives for the duration of the loop, then it wouldn't need to extend the lifetime of &mut self. But that is probably a hard problem for the compiler to solve ;)

I still think it would be nice if this was more clear from the compiler's error message. Maybe even if there were a tool that could desugar the code for me so I could see the explicit lifetimes.