Cannot borrow `*self` as immutable because it is also borrowed as mutable

1

I have created a repo with the current state of my code:

This method:

Needs to return a mutable reference, &mut DataNode, because it will be used by another method, that is upsert(), which adds new nodes into the DataNode. But, the compiler complains, because I need to call methods by using the same &mut self within the same method at #92 and #97, above.

I have also created a change for this:

If I use RefCells, and interior mutability, then I am unable to return data from the borrowed reference, e.g., in ryos/src/main.rs at master · reevik/ryos · GitHub

What options do I have here?

2

This long-standing problem is known as “NLL Problem Case #3”. The borrow checker has difficulty with the combination of

  1. taking a mutable borrow, then based on a condition, either
  2. returning it, or
  3. dropping it and taking a new mutable borrow to the same place.

The workaround is to change one of these things — usually, by avoiding taking a mutable borrow before the condition.

In your case, I would suggest changing locate_range_key so that it returns an index into self.children instead of a reference. This way, it doesn't need to take a mutable borrow, and so query_datanode can make its decision about which of its three branches it follows before any of the possibly-returned mutable borrows are taken.

4 Likes
3

Thanks Kevin. You're saying every time I use the self reference in a method, which is of type "&mut InnerData" and passed as a method argument, it's a new mutable borrow, and the compiler cannot know if the first borrow's lifetime is over (because it doesn't run the code), and therefore it doesn't permit a new borrow later?

4

NLL Problem Case #3 is basically...

    fn query_thru_sibling(&mut self, query_index_key: &Query) -> &mut DataNode {
        //    vvvv (a)
        match &mut self.node.sibling {
            Some(s) => match s {
                // (b) vvvvvvvvvvvvvvvvvvv.....
                TreeNode::INNER(i) => i.query_datanode(query_index_key),
                _ => panic!("Not expected to find a data node sibling!"),
            },
            // Sibling doesn't exist, so we reached the most right branch of the tree.
            None => self.query_thru_last(query_index_key),
        }
    }

...the borrow at (a) is effectively returned[1] at (b), so the compiler concludes that the exclusive borrow at (a) lasts for the rest of the method body.[2] That's why it's saying it's "borrowed as mutable" (exclusively borrowed) in the None branch.

In order for this to not happen, we need more flow-sensitive lifetimes, so that the lifetime is greater than the method body in the Some branch but not the None branch. (The plan is that the next-generation borrow checker, Polonius, will implement this.)

Incidentally, assuming sending the same query twice in a row gives the same result, this signature is unworkable:

    fn query_thru_last(&self, query_index_key: &Query) -> &mut DataNode {

The signature says I should be able to do this:

let one = inner.query_thru_last(&query);
let two = inner.query_thru_last(&query);
use_both(one, two);

But having two &mut _ to the same place usable at the same time is undefined behavior.

  1. the lifetime has to be as long as the return type lifetime ↩︎

  2. The caller chose the lifetime on the &mut self parameter, and thus on the return type, and caller-chosen lifetimes are always a strict superset of the function body. ↩︎

2 Likes
5

I am a bit confused.
How many borrows are there, actually? I thought when I call a method on a struct instance, it is the first borrow which is passed to the method. The second borrow happens when I try to access the sibling, &mut self.node.sibling by using the self. So, I effectively try to obtain a mutable reference to sibling at A. Shouldn't the borrow checker jump in at A and complain there?

6

If I understand, we're talking about reborrows. The borrow checker doesn't complain because the &mut self is inactive for the duration of the reborrow.

1 Like
7

God, thanks. I haven't even heard of reborrowing,
and found this article, which examines the topic:
https://haibane-tenshi.github.io/rust-reborrowing/

8

In brief, the point of reborrowing is that if you have a &'long mut T, you can get another &'short mut T, but only if it's derived from the original, longer borrow. This is because in this case, the compiler can temporarily "freeze" the longer borrow for the duration of the shorter one (since they are related). Thereby it still ensures that no simultaneous mutation actually happens (even though the two mutable references do technically alias), but it also allows "temporary" mutable sub-borrows instead of consuming (and thus rendering unusable) the original borrow.

Reborrows are necessary because without reborrows, there would be no way to write functions like this:

fn push_twice<T>(
    buf: &mut Vec<T>,
    one: T,
    two: T,
) {
    buf.push(one);
    buf.push(two);
}

If reborrowing didn't exist, the first call to Vec::push() would move the mutable reference, and the second call would cause a compile error.

The compiler could not perform such "temporary freezing" if the two mutable references weren't derived from each other, which would lead to concurrent mutation and UB.

1 Like
9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.