if/while Some(n) = &mut foo sugar will leak a temporary mutable borrow to current scope in particular situation

[CGQAQ]

Same Code in the Playground

pub struct Demo {
    foo: Option<Box<Demo>>,
}

// Compiles
pub fn foo1(mut a: &mut Demo) {
    if let Some(ref mut b) = a.foo {
        a = b;
    }
    a.foo = None;
}

// Does not compile
pub fn foo2(mut a: &mut Demo) {
    if let Some(b) = &mut a.foo {
        a = b;
    }
    a.foo = None;
}

// Same Error with foo2
pub fn foo3(mut a: &mut Demo) {
    if let Some(ref mut b) = &mut a.foo {
        a = b;
    }
    a.foo = None;
}

What is exactly difference between foo1 and foo2

ADD: I think foo1 will desuger something like this:

pub fn foo1_desugered(mut a: &mut Demo) {
    match a.foo {
        Some(ref mut _1) => a = _1 ,
        None => ()
    }
    a.foo = None;
}

and foo2 will be like:

pub fn foo2_desugered(mut a: &mut Demo) {
    let mut _t1 = &mut a.foo;
    match _t1 {
        Some(_1) => a = _1 ,
        None => ()
    }
    a.foo = None;
}

ADD#2 And if I explicit add a scope:

// Does not compile
pub fn foo2(mut a: &mut Demo) {
    {
        if let Some(b) = &mut a.foo {
            a = b;
        }
    }
    a.foo = None;
}

pub fn foo2_desugered(mut a: &mut Demo) {
    {
        let mut _t1 = &mut a.foo;
        match _t1 {
            Some(_1) => a = _1 ,
            None => ()
        }
    }
    a.foo = None;
}

same error :(

[Coder-256]

According to The Rust Reference:

By default, identifier patterns bind a variable to a copy of or move from the matched value depending on whether the matched value implements Copy. This can be changed to bind to a reference by using the ref keyword, or to a mutable reference using ref mut

Therefore, in foo1 b is &mut Box<Demo>.

However, in foo2, b is supposed to be Box<Demo> (moved from a.foo). The issue is that a is a borrowed value, so you can't move foo out of it since doing so would make a.foo invalid; you have moved it onto the stack and Rust won't let there be another copy remaining inside a.foo since Box<Demo> does not implement Copy. This is because Rust is conservative and does not allow copying values unless they are manually marked Copy (this is to avoid unintentionally having multiple references to the same data). Once you move a.foo out of a, Rust considers a invalid. Even though inside foo2 you currently hold the mutable reference (hence the sole reference) to a, you do not own a; somebody else (ie. the caller of foo2) owns a and has given you a temporary ability to edit it, and expects it to be valid once you're done. Technically you must ensure that a and all of its fields remain valid for the entire lifetime of a (which in this case outlives foo2).

Let's hypothetically say that Box<Demo> implemented Copy. The code would compile just fine. However, in foo2, b would just be a local copy of a.foo, and modifying it would have no effect on the original copy inside of a.

Another way to think about it, coming from C/C++:

// foo1:
Demo a = b->foo;
a.foo = NULL;

// foo2:
Demo *a = &b->foo;
a->foo = NULL;

Hope this helps.

[CGQAQ]

According to The Rust Reference:

By default, identifier patterns bind a variable to a copy of or move from the matched value depending on whether the matched value implements Copy. This can be changed to bind to a reference by using the ref keyword, or to a mutable reference using ref mut

Let's hypothetically say that Box<Demo> implemented Copy. The code would compile just fine. However, in foo2, b would just be a local copy of a.foo, and modifying it would have no effect on the original copy inside of a.

Another way to think about it, coming from C/C++:

// foo1:
Demo a = b->foo;
a.foo = NULL;

// foo2:
Demo *a = &b->foo;
a->foo = NULL;

Hope this helps.

but in the page you mentioned, also have this:

To service better ergonomics, patterns operate in different binding modes in order to make it easier to bind references to values. When a reference value is matched by a non-reference pattern, it will be automatically treated as a ref or ref mut binding. Example:

let x: &Option<i32> = &Some(3);
if let Some(y) = x {
    // y was converted to `ref y` and its type is &i32
}

I don't think the value of b is moved from a.foo. if it does, compiler should yelling about cannot move out of borrowed value instead of double borrow

[Coder-256]

You're right. In fact, I think foo2 desugars to:

// Does not compile
pub fn foo2(mut a: &mut Demo) {
    if let Some(ref mut b) = &mut a.foo {
        a = b;
    }
    a.foo = None;
}

I think I read your original code too quickly 😅 yeah I'm not sure why this happens. What really confuses me the most is that in both cases, b seems to be &mut Box<Demo>, but I had assumed that in foo2, it would be &mut &mut Box<Demo>. Here's my best guess: in foo1, you have a reference to the value originally in a.foo (so you can modify the object in the original a, but you can't actually modify which value the current a.foo points to). In foo2, you have some kind of automatic reference to the current value of a.foo. In other words, &mut a.foo vs &mut (&mut a).foo. Might also have something to do with how Box can be dereferenced

[stephaneyfx]

@CGQAQ Changing the title to something like "Match ergonomics and explicit ref mut differ in borrow duration" might help classifying the issue.

[ExpHP]

Match ergonomics has nothing to do with it.

if let &mut Some(ref mut b) = &mut a.foo {
    a = b;
}
a.foo = None;

This fails to compile.

Edit: fixed missing ref mut

[ExpHP]

I'll do the same thing I did on this users thread, as I'm glad to have a more minimal example now.

Based on the MIRs of these two snippets:

if let Some(ref mut b) = a.foo {
    a = b;
}
a.foo = None;

Image

if let Some(b) = &mut a.foo {
    a = b;
}

Image

I've constructed what I believe is the MIR of the snippet that won't compile:

if let Some(b) = &mut a.foo {
    a = b;
}
a.foo = None;

Names: _a is a, _b is b, _t is the temp borrow, _d is the discriminat, _n is the literal None.

[stephaneyfx]

@ExpHP I didn't claim that match ergonomics were the culprit. They are one way of reproducing the error and I was just trying to be helpful by suggesting a title closer to the issue.

[ExpHP]

But phrasing it that way makes it sound like a bug in match ergonomics.

[ExpHP]

@rustbot modify labels: +A-borrow-checker

[stephaneyfx]

The RFC 2005 for match ergonomics talks about eventually phasing out ref and ref mut seemingly implying that the form using match ergonomics is equivalent to the form using ref mut. This issue shows that it is not the case, so for a user not well-versed in the compiler innards and how match ergonomics get desugared, that looks like a bug with match ergonomics or ref mut. The title I suggested does not blame one or the other and just states that there is a difference in behavior. I think the current title does not make it easy for someone facing the same problem to find this one.

At any rate, thank you @ExpHP for the time you took to investigate this issue.

Also, if work happens to unify the behavior of the borrow checker there, the following code should also be looked at as I believe it matches the description of the desugaring mentioned in the "Binding mode rules" section of the RFC. I don't know if it is equivalent to the example you already provided.

Playground

pub struct Demo {
    foo: Option<Box<Demo>>,
}

pub fn foo1(mut a: &mut Demo) {
    if let Some(ref mut b) = *&mut a.foo {
        a = b;
    }
    a.foo = None;
}

error[E0506]: cannot assign to `a.foo` because it is borrowed
 --> src/lib.rs:9:5
  |
5 | pub fn foo1(mut a: &mut Demo) {
  |                    - let's call the lifetime of this reference `'1`
6 |     if let Some(ref mut b) = *&mut a.foo {
  |                 ---------     ---------- borrow of `a.foo` occurs here
  |                 |
  |                 assignment requires that `a.foo` is borrowed for `'1`
...
9 |     a.foo = None;
  |     ^^^^^ assignment to borrowed `a.foo` occurs here

[CGQAQ]

if I delete that match expression, everything will be fine

pub fn foo2_desugered(mut a: &mut Demo) {
  {
       let mut _t1 = &mut a.foo;
       // match _t1 {
       //     Some(_1) => a = _1 ,
       //     None => ()
       // }
   }
   a.foo = None;
}

So, I think it's the borrow-checker and match expression problem

[stephaneyfx]

@CGQAQ The assignment to a is crucial to trigger the error because that is what forces the borrow of a.foo to extend to the whole function scope.

pub struct Demo {
    foo: Option<Box<Demo>>,
}

pub fn foo1<'a>(mut a: &'a mut Demo) {
    if let Some(ref mut b) = *&mut a.foo {
        // This assignment is what causes `a.foo` to be borrowed for `'a`
        // because that is what the type of `a` mandates: `&'a mut Demo`
        a = b;
    }
    a.foo = None;
}

pub struct Demo {
    foo: Option<Box<Demo>>,
}

pub fn foo1<'a>(mut a: &'a mut Demo) {
    /* 'b: */ {
        // Just borrowing for `'b`. Nothing forces a borrow for `'a`.
        let _ = &mut a.foo;
    }
    a.foo = None;
}