CODEWITHSUNDEEP
rustborrow-checker
PolyB
PolyB

Reputation: 13

Lifetime mismatch in a double mutable borrow

I'm trying to modify the borrow of a mutable value, here is a minimal example:

fn main() {
    let mut w: [char; 5] = ['h', 'e', 'l', 'l', 'o'];
    let mut wslice: &mut [char] = &mut w;
    advance_slice(&mut wslice);
    advance_slice(&mut wslice);
}

fn advance_slice(s: &mut &mut [char]) {
    let new: &mut [char] = &mut s[1..];
    *s = new;
}

the compiler gives me this error:

error[E0623]: lifetime mismatch
  --> src/main.rs:10:10
   |
8  | fn advance_slice(s: &mut &mut [char]) {
   |                     ----------------
   |                     |
   |                     these two types are declared with different lifetimes...
9  |     let new: &mut [char] = &mut s[1..];
10 |     *s = new;
   |          ^^^ ...but data from `s` flows into `s` here

I've tried to give the same lifetime to both borrow, without success. Also this works if I remove the mutability of w.

Upvotes: 1

Views: 353

Answers (1)

Sven Marnach
Sven Marnach

Reputation: 602545

This error message is indeed unfortunate, and I don't think it provides a good explanation of what's going on here. The issue is a bit involved.

The error is local to the advance_slice() function, so that's all we need to look at. The type of the slice items is irrelevant, so let's take this function definition:

fn advance_slice_mut<T>(s: &mut &mut [T]) {
    let new = &mut s[1..];
    *s = new;
}

The first line creates a new slice object starting after the first item of the original slice.

Why is this even allowed? Don't we have two mutable references to the same data now? The original slice *s includes the new slice new, and both allow modifying data. The reason this is legal is that *s is implicitly reborrowed when creating the subslice, and *s cannot be used again for the lifetime of that borrow, so we still have only one active reference to the data in the subslice. The reborrow is scoped to the function advance_slice_mut(), and thus has a shorter lifetime than the original slice, which is the root cause of the error you get – you are effectively trying to assign a slice which only lives until the end of the function to a memory location that lives longer than the function call.

This kind of implicit reborrow happens everytime you call a function that takes an argument by mutable reference, including in the implicit call to index_mut() in &mut s[1..]. Mutable references can't be copied, since this would create two mutable references to the same memory, and the Rust language designers decided that an implicit reborrow is the more ergonomic solution than moving mutable references by default. The reborrow does not happen for shared references, though, since they can be freely copied. This means that &s[1..] will have the same lifetime as the original scope, since it is perfectly fine for two overlapping immutable slices to coexist. This explains why your function definition works fine for immutable slices.

So how do we fix this problem? I believe that what you intend to do is perfectly safe – after reassigning the new slice to the old one, the old one is gone, so we don't have two concurrent mutable references to the same memory. To create a slice with the same lifetime as the original slice in safe code, we need to move the original slice out of the reference we got. We can do this by replacing it with an empty slice:

pub fn advance_slice_mut<T>(s: &mut &mut [T]) {
    let slice = std::mem::replace(s, &mut []);
    *s = &mut slice[1..];
}

Alternatively, we can also resort to unsafe code:

use std::slice::from_raw_parts_mut;

pub fn advance_slice_mut<T>(s: &mut &mut [T]) {
    unsafe {
        assert!(!s.is_empty());
        *s = from_raw_parts_mut(s.as_mut_ptr().add(1), s.len() - 1);
    }
}

Upvotes: 5

Related Questions