Mutable borrow of field with autoref vs ref mut

[davidhewitt]

I've been playing around with a singly-linked-list. It turns out that this method, which I had hoped might compile with help of non-lexical-lifetimes, does not compile:

struct Recursive {
    child: Option<Box<Recursive>>
}

impl Recursive {
    fn mut_back(&mut self) -> &mut Self {
        let mut node = self;
        while let Some(child) = node.child.as_mut() {
            node = child
        }
        node
    }
}

The error is stating that the borrow for node.child overlaps with the returned borrow of node, as seen below:

error[E0499]: cannot borrow `*node` as mutable more than once at a time
  --> src/lib.rs:11:13
   |
6  |         fn mut_back(&mut self) -> &mut Self {
   |                     - let's call the lifetime of this reference `'1`
7  |             let mut node = self;
8  |             while let Some(child) = node.child.as_mut() {
   |                                     ---------- first mutable borrow occurs here
...
11 |             node
   |             ^^^^
   |             |
   |             second mutable borrow occurs here
   |             returning this value requires that `node.child` is borrowed for `'1`

error: aborting due to previous error

There is a very similar implementation of mut_back() which does compile:

impl Recursive {
    fn mut_back_good(&mut self) -> &mut Self {
        let mut node = self;
        while let Some(ref mut child) = node.child {
            node = child
        }
        node
    }
}

What I think is going on to cause the first implementation to fail is the call to child.as_mut(). Presumably due to autoref this creates a new unique borrow on node.child.

In the second case, I understand that the ref mut binding means we're also creating a unique borrow on node.child. But in this case the borrow checker doesn't think this new unique borrow is a problem.

It seems to me that the compiler should be able to treat these two implementations equally?

[davidhewitt]

I found a variant of the above which looks a lot like a typical NLL problem:

struct Recursive {
    child: Option<Box<Recursive>>,
}

impl Recursive {
    fn child_or_self_bad(&mut self) -> &mut Self {
        match self.child.as_deref_mut() {
            Some(child) => child,
            None => self
        }
    }
    
    fn child_or_self_good(&mut self) -> &mut Self {
        match self.child {
            Some(ref mut child) => child,
            None => self
        }
    }
}

child_or_self_bad does not compile, but child_or_self_good does.

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

[dhardy]

Thanks for reporting. I've hit what I believe is the same error twice recently; once as in your child_or_self_bad method and the other time via a loop as follows.

The broken version (borrow conflicts with the same borrow, i.e. self.get_mut(i), from the previous iteration):

        for i in 0..self.len() {
            if let Some(w) = self.get_mut(i) {
                if id > w.id() {
                    continue;
                }
                return w.find_mut(id);
            }
            break;
        }

Working version:

        for i in 0..self.len() {
            if self.get(i).map(|w| id > w.id()).unwrap_or(true) {
                continue;
            }
            if let Some(w) = self.get_mut(i) {
                return w.find_mut(id);
            }
            break;
        }

(Code is extracted from WidgetCore::find_mut.)

[mbrubeck]

I believe this is a duplicate of #62013.

The test case in this bug (as in that one) compiles successfully with rustc -Z polonius.

[liufuyang]

@mbrubeck Thank you. I encountered this as well and do we have plans to fix it? Also do you know is there a way to use -Z polonius with cargo?

[mbrubeck]

Thank you. I encountered this as well and do we have plans to fix it?

It looks like it will be fixed when Polonius becomes stable, at the latest. It would be nice to fix it before then, but I don't know whether anyone is working on that yet.

Also do you know is there a way to use -Z polonius with cargo?

You can set the $RUSTFLAGS environment variable, or create a config.toml file and set the rustflags key. However, please note that Polonius is still experimental.