CODEWITHSUNDEEP
rustannotationslifetime
nonergodic
nonergodic

Reputation: 13

Explicit lifetime annotations toy example

I'm trying to figure out a Rust lifetime issue and after boiling it down a bunch, I realized that I have no idea how I would explicitly annotate the lifetimes of r, x2, and _arr in foo:

struct X<'a> {
    _v: &'a mut i32,
}

fn main() {
    let mut v1 = 0;
    let x1 = X { _v: &mut v1 };
    foo(x1);
}

fn foo(x1: X) {
    let mut v2 = 1;
    let r = &mut v2;
    let x2 = X { _v: r };
    let _arr = [x1, x2];
}

Upvotes: 1

Views: 334

Answers (1)

Ian S.
Ian S.

Reputation: 1961

I'm going to work off of the assumption that the part of your code that got cut off is the following:

struct X<'a> {
    _v: &'a mut i32,
}

In that case, let's dissect what's going on in foo a little bit.

fn foo(x1: X) {
    // Lives until the end of the function, call its lifetime 'v2
    let mut v2 = 1;
    // Borrow v2 for some lifetime 'r which is no longer than 'v2
    // so r is of type &'r mut i32
    let r = &mut v2;
    let x2 = X { _v: r }; // x2 is of type X<'r>
    let _arr = [x1, x2]; // ??
}

The confusion probably comes from the fact that x1 seems to have an ambiguous lifetime in its type. This is because we didn't explicitly specify the lifetime in x1: X. This is a Rust 2018 idiom, and I personally recommend not doing this. You can add #![deny(rust_2018_idioms)] to the top of your crate root and the compiler will point out these ambiguities to you and force you to be more explicit. What happens here is that the function declaration gets de-sugared to the following:

fn foo<'x1>(x1: X<'x1>) { ... }

Now it is implied that the lifetime 'x1 extends at least through the body of foo, and this makes sense because it kind of has to. If something which lived for 'x1 was freed in the middle of foo (disregarding how something like that could even happen), then that would defeat the point of using lifetimes for memory safety.

So that being said, let's revisit this line:

let _arr = [x1, x2];

We know that x2 is of the type X<'r> and that 'r extends at most to the end of foo (since 'r is no longer than 'v2 and 'v2 extends to the end of foo). Moreover, we know that x1 is of the type X<'x1> and that 'x1 extends at least to the end of foo. This means that 'x1 is at least as long as 'r. Since lifetimes are covariant, this means that X<'x1> is a sub-type of X<'r>, since whenever we require a value of the type X<'r> we can safely substitute in one of type X<'x1> instead. So what happens is _arr is given the type [X<'r>; 2], and upon construction the lifetime on x1 is shortened to 'r.

We can actually test this hypothesis to see if it's correct. What would happen if the compiler wasn't allowed to shorten that lifetime? In other words, what if the lifetime on X was not covariant. If we modify X as follows then its lifetime type parameter is made invariant:

struct X<'a> {
    _v: &'a mut i32,
    _invariant: PhantomData<fn(&'a ()) -> &'a ()>
}

And sure enough, after adding the _invariant field in the appropriate places to make the code compile, we receive the following error:

   |
14 | fn foo<'x1>(x1: X<'x1>) {
   |        --- lifetime `'x1` defined here
15 |     let mut v2 = 1;
16 |     let r = &mut v2;
   |             ^^^^^^^ borrowed value does not live long enough
17 |     let x2 = X { _v: r, _invariant: PhantomData };
   |                      - this usage requires that `v2` is borrowed for `'x1`
18 |     let _arr = [x1, x2];
19 | }
   | - `v2` dropped here while still borrowed

Now how do we know the compiler wasn't extending the lifetime 'r to 'x1 in the first place? Well if it was doing that, then we could modify foo to do the following, which would unequivocally cause a use-after-free:

fn foo<'x1>(x1: X<'x1>) -> &'x1 mut i32 {
    let mut v2 = 1;
    let r = &mut v2;
    let x2 = X { _v: r };
    let _arr = [x1, x2];
    _arr[1]._v
}

And sure enough if you try the code above it fails to compile with the reason given being that we're returning a reference to a local variable. Moreover, if you try returning _arr[0]._v, then you get the exact same error.

Sub-typing and variance can be pretty hard to grasp and it's not something you need to fully understand to be an effective Rust programmer. Nonetheless, it is very interesting and you can learn more about it here in the Rustonomicon.

Upvotes: 3

Related Questions