Diagnostics for two-phase borrows are confusing and unhelpful

[Rik-de-Kort]

When I have a struct with two methods on the impl, both borrowing self mutably, I cannot chain the functions, like s.second(s.first()): I get a borrow checker error. Instead, I have to assign s.first() to an auxiliary variable. Might be related to #21906 but could not find any other similar issues.

struct S{}

impl S{
    fn first(&mut self) -> bool{
        true
    }
    
    fn second(&mut self, b: bool) {
        if b { println!{"Hello, world!"}; }
    }
}

fn main() {
    let mut s = S{};
    s.second(s.first());
}

I expected to see this happen: a simple print of "hello world!"

Instead, this happened:

   Compiling playground v0.0.1 (/playground)
error[E0499]: cannot borrow `s` as mutable more than once at a time
  --> src/main.rs:15:14
   |
15 |     s.second(s.first())
   |     - ------ ^ second mutable borrow occurs here
   |     | |
   |     | first borrow later used by call
   |     first mutable borrow occurs here

error: aborting due to previous error

For more information about this error, try `rustc --explain E0499`.
error: could not compile `playground`

To learn more, run the command again with --verbose.

It works fine if we use an auxiliary variable, which looks quite ugly to my mind:

fn main() {
    let mut s = S{};
    let f = s.first();
    s.second(s.first());
}

Playground link

[jyn514]

This is 'intended' behavior in that it's not a bug: your code desugars to

S::second(&mut s, S::first(&mut s))

and now you can see that it's borrowed for second before the call to first. That said, the behavior is definitely unintuitive; see #56254.

[camelid]

Implementing #77834 should fix this.

[Rik-de-Kort]

This is 'intended' behavior in that it's not a bug: your code desugars to

S::second(&mut s, S::first(&mut s))

and now you can see that it's borrowed for second before the call to first. That said, the behavior is definitely unintuitive; see #56254.

This means I can learn something here, because I thought Rust was call by value? So wouldn't (or shouldn't) the bytecode calculate S::first(&mut s) first before entering the function? Or is there some parallel evaluation of arguments magic going on so that the compiler can't guarantee this?

[jyn514]

Rust borrows the arguments in order: because &mut s comes before the call to first(), it's mutably borrowed before and can't be borrowed again. 'call by value' doesn't have anything to do with it.

[jyn514]

I'm going to close this as a duplicate of #77834, but I agree the diagnostic here should be improved.