Expanding lifetime error messages

compiler
1

I have run into a bit of an annoying lifetime issue last night that I still haven’t really been able to figure out. Basically, I’m trying to diagnose the following error message:

error: `content` does not live long enough
   --> src/parse/repeat.rs:144:5
    |
131 |         let _ = { drop(::apply(&content, ::Options::default(), parser)) };
    |                                 ------- borrow occurs here
...
144 |     }
    |     ^ `content` dropped here while still borrowed
    |
    = note: values in a scope are dropped in the opposite order they are created

error: aborting due to previous error

My issue here stems from the fact that I don’t know what keeps the borrow alive, and why. It is an error that only comes up when certain conditions are met, making it hard to reduce.

I have been wondering: rustc already has that information, since it used it to decide that the above is not safe. Would it be possible to add that information to the error message? I was thinking something along the lines of:

note: Value 'content' is still borrowed by [the return value, the argument X, etc] type SomeType<'somelifetime> due to [constraint X on parameter Y, etc]"
2 Likes
2

I’m not sure either what keeps it alive, so a better message would definitely be useful.

One frequent gotcha is that expressions in function call live longer than the function call, and need to be stored in a temp variable like this, so maybe it’s the case here too?

let tmp = ::apply(&content, ::Options::default(), parser);
drop(tmp);
3

Unfortunately that makes no difference :slight_smile: I have tried many explicit releases, but none worked. In this case, it seems to think the content is referenced in the parser sent to apply, for some reason I’m not sure of.

But I do keep running into issues like these. Usually I can figure out the root cause, but in some cases like these I’m stumped. And even when I find a solution, most of my time is spent trying to figure out why rustc thinks the borrow is kept alive somewhere, once that is clear the fix (or design issue) is usually much more obvious.

So I thought more information in error messages might be a better long term solution :slight_smile:

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.