feat: early late classification of lifetimes

[dfireBird]

Some things to note:

1. We still don't handle the HRTB Lifetimes (in both where and fn ptr) and will be done in a future PR and that PR should also remove the in_binders and fully replace it with bound_vars stack.
2. I haven't added a new tests, not sure how to test this particularly, so any approach to test them are helpful (this should be done before merging)
3. There are some IDE features which lose information that I consider to be essential, need to find a way to not have that loss of information (see FIXME in ide tests)
4. I have implemented this to best of my understanding of both r-a and rustc, so if there are panics or data mismatch, I'm really sorry that happened, I'll try to fix it as soon as I get to know about it.

[ChayimFriedman2]

Awesome work!

View changes since this review

[ChayimFriedman2]

I wonder if we should have different arenas for the early and late bound lifetimes, so locating a lifetime param's index can be O(1).

[dfireBird]

Coming to this (I kept this to the last), we can't do that with what we have. Since we don't know if lifetime is late bound or early bound until after we finish our hir-def lowering. We can not mutate the arena itself that will make the Idx of that arena to be invalidated.

[ChayimFriedman2]

True, but we don't need the Idx during lowering. We can just make the arenas after we finish lowering.

[dfireBird]

If that's the case, I'll try doing something.

[dfireBird]

It was fairly simple to get it to compile without errors, the only thing I find problematic is implementation of std::ops::Idx<LocalLifetimeParamId>, which lifetime arena to choose? We are currently (with my changes ofc) indexing with both early and late lifetimes.

[ChayimFriedman2]

They need to have a different ID, otherwise many things will be problematic.

[dfireBird]

I feel like that's unnecessary complexity for an optimization that would only benefit two methods, the new lifetime_param_idx and len_late_bound_lifetimes. Both for which can be handled through pre-computing and storing those value.

[ChayimFriedman2]

I didn't say we should do this, I was only wondering whether it's better. But do note that these methods may be fairly hot.

[dfireBird]

Yeah I get it.

I was just voicing out my thoughts 😅 .

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.