feat: implement lifetime elision by dfireBird · Pull Request #22927 · rust-lang/rust-analyzer

dfireBird · 2026-07-27T03:38:12Z

No description provided.

dfireBird · 2026-07-27T04:25:06Z

Not sure why this fails in CI and passes in my system?

ShoyuVanilla · 2026-07-27T05:17:49Z

Not sure why this fails in CI and passes in my system?

rust-analyzer/docs/book/src/contributing/README.md

Line 67 in 85e85df

Use `env RUN_SLOW_TESTS=1 cargo test` to run the full suite.

You need to set an extra env var to run slow tests

dfireBird · 2026-07-27T05:58:17Z

Oh I didn't know, we ran slow tests. My bad 😅

Veykril

Only a partial review so far

View changes since this review

Veykril · 2026-07-27T08:00:37Z

+                lc world &WorldSnapshot [type_could_unify+name+local]
+                ex world  [type_could_unify]


Interesting, so we lose a lot of type equality now which I guess makes sense. Worth to keep in mind if we want t o have something like type-equal modulo lifetimes

Veykril · 2026-07-27T08:04:29Z

Very excited for this, I've been wanting this for so long!

ChayimFriedman2

Round 1 review.

View changes since this review

dfireBird · 2026-08-03T06:00:29Z

Two tests will be failing, one of which I think value in expect is correct but after infer it gets turned into a RegionKind::Error, which make the test fail (within the expect)
Other fails because of failure of const eval query, because we are passing empty generic args to query (here), not sure how to fix this or should we let the const eval fail?.

ChayimFriedman2 · 2026-08-03T06:12:59Z

Const eval doesn't care about lifetimes, as long as you only have lifetimes there you can pass erased or identity.

dfireBird · 2026-08-03T11:48:25Z

I'm not sure what you mean?

ChayimFriedman2 · 2026-08-03T13:40:56Z

If all args are lifetime, you can pass a dummy GenericArgs, with RegionKind::ReErased or GenericArgs::identity_for_item().

dfireBird · 2026-08-03T15:14:44Z

Passing the GenericArgs::identity_for_item() (let me know if I made a mistake there, once I push) make the test pass as is. Thanks for the help.

dfireBird · 2026-08-03T16:48:34Z

Found out why we get error region on other test, when we resolve the types, we fold the ReVar into a ReError here: https://github.com/rust-lang/rust-analyzer/blob/master/crates/hir-ty/src/infer/unify.rs#L705-L713, then I think this is expected behavior for this test, if so then I'll revert the expect on that test as well?

Veykril · 2026-08-04T09:42:57Z

+    fn elide_return_lifetime(&mut self) {
+        let old_elision_kind =
+            mem::replace(&mut self.lifetime_elision_kind, LifetimeElisionKind::Error);
+
+        let new_elision_kind =
+            if let LifetimeElisionKind::NewLifetimeParam { return_lt, total_created, .. } =
+                old_elision_kind
+            {
+                let lifetime_param_id =
+                    return_lt.and_then(|(lifetime_param_id, elided_source)| match elided_source {
+                        ArgumentElisionContext::Self_ => Some(lifetime_param_id),
+                        ArgumentElisionContext::Param if total_created == 1 => {
+                            Some(lifetime_param_id)
+                        }
+                        ArgumentElisionContext::Param => None,
+                    });
+                LifetimeElisionKind::Lifetime(lifetime_param_id)
+            } else {
+                unreachable!("Method should not be called with other lifetime_elision_kind")
+            };
+        self.lifetime_elision_kind = new_elision_kind;
+    }


This setup doesn't quite handle these correctly i think

fn get<'a>(&'a self) -> &str fn identity<'a>(value: &'a str) -> &str type Callback = for<'a> fn(&'a str) -> &str;

These are valid signatures that participate in elision. The return types here all have 'a as their elided lifetimes.

And for this it incorrectly elides to y's lifetime.

fn bad<'a>(x: &'a str, y: &str) -> &str

That signature is an error, return type elision only happens if the args have exactly one lifetime (or if there is a self param).

Reason being that lower_lifetime_ref doesn't participate (from what I can tell in lifetime_elision_kind).

View changes since the review

I have done the return type elision very haphazardly, I should take a look at it and fix it.

I think I should introduce a new LifetimeRef for elided lifetimes or designate LifetimeRef:::Param and LifetimeRef::HrtbParam only to be used for elided (by renaming or something). Because with the fix I'm doing for this, a function like this:

fn identity<'a>(value: &'a str) -> &str // would be lowered and printed as fn identity<'a>(value: &'a str) -> &'a str

Because I use the LifetimeRef itself, since this is also a valid elision:

fn identity(value: &'static str) -> &str // it would lower and print fn identity(value: &'static str) -> &'static str

Note that the LifetimeRefId are different in argument and return but the LifetimeRef itself will be same.

The way elision works, is that first you lowered the args. Then you take all lifetimes defined from the args and for<...> in the fn, in other words all HRTB lifetimes in the last HRTB stack entry for fn ptrs or all lifetime params in a fn definition. If there is exactly one, all elided lifetimes in the return type get it. Otherwise, eliding lifetimes in the return type is an error.

Yeah I understand that now and is somewhat similar to what I have done, but as you can see from question above since I re-use the LifetimeRef of the lifetime (be it elided or named or static) that can be used for return type, it would result in lowering and analysis that comes after HIR lowering to think, the lifetime in return type was actually provided.

What is the problem that the code will think that the lifetimes were provided? What does it matter for?

Like for the two test we ignored in ide-diagnostic.

Not sure what the actual behavior is, need to check rustc.

Well I didn't check the rustc code itself, but I printed out the HIR tree for some of the functions discussed here and it seems it's all input lifetimes.

Like for the two test we ignored in ide-diagnostic.

The end-goal is to remove the elision in hir-ty.

Well I didn't check the rustc code itself, but I printed out the HIR tree for some of the functions discussed here and it seems it's all input lifetimes.

But what is an input lifetime? Any lifetime mentioned in the input?

Input lifetimes are lifetimes used in the parameters, output are the ones in the return type

https://doc.rust-lang.org/reference/lifetime-elision.html?highlight=elision#lifetime-elision-in-functions

Each elided lifetime in the parameters becomes a distinct lifetime parameter.

If there is exactly one lifetime used in the parameters (elided or not), that lifetime is assigned to all elided output lifetimes.

In method signatures there is another rule

If the receiver has type &Self or &mut Self, then the lifetime of that reference to Self is assigned to all elided output lifetime parameters.

So this is the function in rustc that retrieves the candidate for return elision: resolve_fn_params

It records distinct lifetime usages separately for each input type. I think I make some refactors based on this. But I think my current implementation (unpushed) is very similar.

Also based on this: https://github.com/rust-lang/rust/blob/main/compiler/rustc_hir/src/def.rs#L932-L964
We can consider LifetimeRef::Param to be elided always?

ChayimFriedman2

Review round 2.

I do wonder if we should resolve all lifetimes during hir lowering, instead of hir-ty, and tend towards yes. But this is not for this PR.

View changes since this review

ChayimFriedman2 · 2026-08-05T00:45:46Z

    is_lowering_coroutine: bool,

-    for_type_binder: Option<ThinVec<Name>>,
+    lifetime_arena: Option<&'a mut Arena<LifetimeParamData>>,


This should be in LifetimeElisionKind::NewLifetime. This way we avoid the Option and unwrap().

I added this as separate field so that I could do this https://github.com/rust-lang/rust-analyzer/blob/master/crates/hir-def/src/expr_store/lower.rs#L399 and not have two mutable borrows to lifetime arena.
It's now on ExprCollector: https://github.com/dfireBird/rust-analyzer/blob/lifetime_elision/crates/hir-def/src/expr_store/lower.rs#L422

This does not prevent it from being a field on LifetimeElisionKind::NewLifetime, this is the active variant when that function is called.

It's not an active variant, since we call it after the lowering the return type, LifetimeElisionKind::Lifetime for the return type lifetime and we need the named lifetime in return as well for the method to work.

Not sure what you talk about (and the links have rotten now), but this is certainly possible, see how I implemented that in https://github.com/ChayimFriedman2/rust-analyzer/tree/lt-arena-in-variant.

So when the update_to_late_bound_lifetimes is called, the lifetime_elision_kind is Lifetime variant not the NewGenericLifetime because the variant is changed before lowering the return type.

Veykril · 2026-08-05T06:40:42Z

I do wonder if we should resolve all lifetimes during hir lowering, instead of hir-ty, and tend towards yes. But this is not for this PR.

Yes I think we should

Veykril · 2026-08-05T06:41:36Z

Also I really appreciate you tackling this complex task up @dfireBird! (whether you knew how much work this was gonna end up being or not 😄)

dfireBird · 2026-08-05T13:41:28Z

Also I really appreciate you tackling this complex task up @dfireBird! (whether you knew how much work this was gonna end up being or not 😄)

I did not know it would be this much but this is fun compared to my day-to-day work :)

Also, sorry I've been ignoring @ChayimFriedman2 round 2 Review, will get to it, once I finish the return elision correctly.

dfireBird · 2026-08-11T15:06:05Z

Now that we merged two TypeBound variants and it has 3 fields, should we make it a struct variant instead of a tuple variant? I think it would much more readable as well while matching?

ChayimFriedman2

Review round 3, focusing on after-hir-def changes and answering your previous question. I will review the rest of the changes but didn't want to delay the rest for that.

This is now feeling close to merge-able! Excited for this, and thank you for all the hard work!

View changes since this review

ChayimFriedman2 · 2026-08-27T21:59:31Z

                    "{name}[{}]\n",
                    generics(&db, def)
-                        .iter(false)
+                        .iter(true)


Actually this is not correct: late bound parameters have no variance. We can still solve for them (it's just meaningless), but displaying them here is confusing.

So if have to change it to false here, I'll have to change to false here as well, would that be fine?

rust-analyzer/crates/hir-ty/src/variance.rs

Line 63 in af4111f

let count = generics.len(true);

It should be but only if you verify that this does not cause bugs due to wrong generic param indices.

I can check rustc once and see what they do.

ChayimFriedman2 · 2026-08-28T06:49:23Z

    is_lowering_coroutine: bool,

-    for_type_binder: Option<ThinVec<Name>>,
+    lifetime_arena: Option<&'a mut Arena<LifetimeParamData>>,


Not sure what you talk about (and the links have rotten now), but this is certainly possible, see how I implemented that in https://github.com/ChayimFriedman2/rust-analyzer/tree/lt-arena-in-variant.

ChayimFriedman2 · 2026-08-28T06:50:22Z

+}
+
+#[derive(Debug)]
+pub enum LifetimeElisionKind {


Placeholder, which means we cannot remove it...

ChayimFriedman2 · 2026-08-28T14:35:12Z

    let mod_path = Interned::new(ModPath::from_segments(kind, segments));

+    let (resolved_module_def_id, is_trait_assoc_item) = {
+        let (per_ns, remaining_idx) = collector.def_map.resolve_path(


Wait a minute... This resolves every path, even in the body. You should absolutely not do that.

View changes since the review

Perhaps we can put this under the same conditions that happen below like: collector.lifetime_elision_kind.can_elide() || old_lifetimes_constrained_by_input.is_some()?

minor fixes related to review comments

fix: should elide lifetime in impl trait and its tests

refactor: collect_path_elided lifetimes function

rustbot · 2026-09-03T15:23:05Z

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.

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 27, 2026

dfireBird force-pushed the lifetime_elision branch from 06a014c to 88e02b3 Compare July 27, 2026 06:04

Veykril reviewed Jul 27, 2026

View reviewed changes

ChayimFriedman2 requested changes Jul 28, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

dfireBird force-pushed the lifetime_elision branch from e4832ca to 6526ecd Compare August 4, 2026 02:39

This comment has been minimized.

Sign in to view

Veykril reviewed Aug 4, 2026

View reviewed changes

Comment thread crates/hir-def/src/expr_store/lower.rs

ChayimFriedman2 requested changes Aug 5, 2026

View reviewed changes

Veykril changed the title ~~internal: implement lifetime elision~~ feat: implement lifetime elision Aug 5, 2026

dfireBird force-pushed the lifetime_elision branch 4 times, most recently from a9955b7 to dccc657 Compare August 9, 2026 05:25

Wilfred mentioned this pull request Aug 10, 2026

fix: Off-by-one in lifetime binders when lowering dyn Trait<'a> #23107

Merged

dfireBird force-pushed the lifetime_elision branch from d1a5d86 to 232fe69 Compare August 11, 2026 15:52

This comment has been minimized.

Sign in to view

dfireBird force-pushed the lifetime_elision branch from 232fe69 to e0c2aff Compare August 13, 2026 11:48

This comment has been minimized.

Sign in to view

ChayimFriedman2 requested changes Aug 28, 2026

View reviewed changes

ChayimFriedman2 reviewed Aug 28, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

dfireBird force-pushed the lifetime_elision branch from e0c2aff to 0f7fce7 Compare September 1, 2026 17:29

This comment has been minimized.

Sign in to view

dfireBird added 9 commits September 3, 2026 19:05

internal: implement lifetime elision

2ba5bd0

fix: tests updated for lifetime ellision

9a3ef87

fix: hide elided lifetimes in references and generic param list

601ff10

minor fixes related to review comments

refactor: change elision callbacks to internal state

b9099d8

fix: const eval failing on generic args

501cf54

fix: lower elided lifetime in return types

34de846

fix: should elide lifetime in impl trait and its tests

refactor: make for_binder as an variant in lifetime elision kind

af1e1fd

chore: merge TypeBound::ForLifetimes into TypeBound::Path

0b77903

fix: update elided lifetime display in tests

d12f863

refactor: collect_path_elided lifetimes function

dfireBird force-pushed the lifetime_elision branch from 0f7fce7 to d12f863 Compare September 3, 2026 15:23

		lc world &WorldSnapshot [type_could_unify+name+local]
		ex world [type_could_unify]

Uh oh!

Uh oh!

Conversation

dfireBird commented Jul 27, 2026

Uh oh!

dfireBird commented Jul 27, 2026

Uh oh!

ShoyuVanilla commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dfireBird commented Jul 27, 2026

Uh oh!

Veykril left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Veykril Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Veykril commented Jul 27, 2026

Uh oh!

ChayimFriedman2 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dfireBird commented Aug 3, 2026

Uh oh!

ChayimFriedman2 commented Aug 3, 2026

Uh oh!

dfireBird commented Aug 3, 2026

Uh oh!

ChayimFriedman2 commented Aug 3, 2026

Uh oh!

dfireBird commented Aug 3, 2026

Uh oh!

dfireBird commented Aug 3, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

Veykril Aug 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dfireBird Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dfireBird Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Veykril Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dfireBird Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

ShoyuVanilla commented Jul 27, 2026 •

edited

Loading

Veykril left a comment •

edited by rustbot

Loading

Veykril Jul 27, 2026 •

edited

Loading

ChayimFriedman2 left a comment •

edited by rustbot

Loading

Veykril Aug 4, 2026 •

edited by rustbot

Loading

dfireBird Aug 5, 2026 •

edited

Loading

dfireBird Aug 5, 2026 •

edited

Loading

Veykril Aug 5, 2026 •

edited

Loading

dfireBird Aug 5, 2026 •

edited

Loading

ChayimFriedman2 left a comment •

edited by rustbot

Loading

dfireBird Aug 6, 2026 •

edited

Loading

dfireBird commented Aug 11, 2026 •

edited

Loading

ChayimFriedman2 left a comment •

edited by rustbot

Loading