Lifetime woes :(


Please ignore the mess of code. It’s still PoC…

I’ve been stuck on this for the past couple of days.

The offending line is 339:

It works if I change the line to:

c.insert(0, PARSE_TREE::TERMINAL("TEST"));

So my understanding is that it has something to do with the (differing?) lifetimes of c and u, but I’m confused and at a standstill on how to fix it. It’s driving me crazy.

I’m also not sure why the error message is referring to a line that has nothing to do with the offending line?


Instead of,

fn _parse<'a, '__elided1, '__elided2, '__elided3>(
    parse_table: &'a PARSE_TABLE<'__elided1>,
    parse_tree:  &'a mut PARSE_TREE<'__elided2>,
    input_stack: &'a mut INPUT_STACK<'__elided3>,

you probably meant:

fn _parse<'a, '__elided1, '__elided2, '__elided3>(
    parse_table: &'__elided1 PARSE_TABLE<'a>,
    parse_tree:  &'__elided2 mut PARSE_TREE<'a>,
    input_stack: &'__elided3 mut INPUT_STACK<'a>,

In the former case, the lifetime of the inner strings of the three parameters are all unrelated, whereas in the latter case the lifetime of the interior strings are all the same. Generally speaking, the lifetime of inner objects can be less flexible because &mut makes the lifetimes invariant (can’t ever shrink) rather than covariant (can shrink if needed). In this case, omitting the top-level lifetimes has no impact, but the inner lifetimes really matter because of &mut.


OMG, that worked!

Thank you so much @Fylwind.

Can you please send me your Bitcoin address as a token of my appreciation!!

PS: Also, what tool did you use to view all of that ‘__elidedX’ output?


Thanks. No need to but I appreciate the thought :slight_smile:

PS: Also, what tool did you use to view all of that ‘__elidedX’ output?

Nothing, I wrote them out manually using the rules:


I have to let you know, you’re awesome. If I’m ever in your area, track me down… dinner is on me!!!

Ah. It’s very GCC like :slight_smile:

Thanks again!