internal: 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-27T07:55:52Z

+                if let Some(binder) = &fn_.binder
+                    && !binder.is_empty()


nit, lets drop the is_empty check. Ideally we'd just lower to None when binder is empty

Yeah I guess, I should've kept None if the binder is empty after fn ptr lowering instead of this and that makes sense as well.

Veykril · 2026-07-27T07:56:46Z

-    pub scope: GenericDefId,
-    pub local_id: usize,
-}
+pub struct HrtbLifetimeParamId(pub usize);


Suggested change

pub struct HrtbLifetimeParamId(pub usize);

pub struct HrtbLifetimeParamId(pub u32);

We wont ever have that many lifetimes, so being conservative for memory usage won't hurt here

Veykril · 2026-07-27T07:57:13Z

            LifetimeRef::Param(lifetime_param_id) => {
                Some(LifetimeNs::LifetimeParam(*lifetime_param_id))
            }
+            LifetimeRef::HrtbParam(_) => None, // this should be unreachable, should we panic?


Suggested change

LifetimeRef::HrtbParam(_) => None, // this should be unreachable, should we panic?

LifetimeRef::HrtbParam(_) => {

never!();

None

}

Veykril · 2026-07-27T07:57:53Z

            TypeRef::Fn(fn_) => {
-                if let Some(binder) = &fn_.binder {
+                if let Some(binder) = &fn_.binder
+                    && !binder.is_empty()


Veykril · 2026-07-27T07:59:35Z

 fn bar(x: &u32) {}
 "#,
-        expect!["ty: &'_ &'_ u32, name: x"],
+        expect!["ty: &'_ &'<erased> u32, name: x"],


we probably need to check our rendering now, we shouldn't show erased lifetimes to the user

I could make the RegionKind::ReErased to display '_ for now, would that be fine?

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 module lifetimes

Veykril · 2026-07-27T08:02:26Z

We should definitely not render '_ in the generic param list 🙈 if we can't yet render the elided lifetimes nicely here we should probably hide them wholesale

Would it be fine, if we still showed them in the argument list?

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

ChayimFriedman2 · 2026-07-28T18:56:49Z


            ```rust
-            pub fn foo(_: &Path)
+            pub fn foo<'_>(_: &'_ Path)


IMO this is worse display. I think we should omit '_ generics, and omit them for references as well. For non-references - I'm not sure.

Agree'd, this should mimic the lint. So rendering '_ for paths is good, for references we should skip as its always implied.

I think it comes down to what I was saying before in zulip chat #t-compiler/rust-analyzer > Lifetime elision @ 💬, have a way to determine if a LifetimeRef is elided or not, provided we have ExpressionStore.

You could check the name for '_, or add another way to differentiate.

I could indeed check for LifetimeRef::Param, but if it's going to be used in other places, it's going to be a bit of problem.

But only elided lifetimes can have name '_.

Oh I realized something that I can do, I'll try that.

ChayimFriedman2 · 2026-07-28T18:59:10Z


+    #[inline]
+    pub fn anon_lifetime() -> Name {
+        Self::new_text("'_")


This should be a predefined symbol.

ChayimFriedman2 · 2026-07-28T18:59:58Z

+            ModuleDefId::StaticId(id) => Some(id.into()),
+            ModuleDefId::TraitId(id) => Some(id.into()),
+            ModuleDefId::TypeAliasId(id) => Some(id.into()),
+            _ => None,


Use exhaustive matching here.

ChayimFriedman2 · 2026-07-28T19:06:07Z

+                        self.lower_type_ref(
+                            it,
+                            impl_trait_lower_fn,
+                            &mut Self::elided_lifetime_placeholder_allocator,


This does not look correct. We should first lower the arguments. If there is exactly one HRTB lifetime in them, any elided lifetime in the return type should refer to it. Otherwise, it's an error lifetime (plus a diagnostic). In fact, I'm pretty sure we should remove LifetimeRef::Placeholder.

I use LifetimeRef::Placeholder for return types, so that I can resolve it correctly during hir-ty lowering. But I missed to copy from my old WIP of the lifetime elision.

I see no reason to resolve it during hir-ty lowering and complicate the code with additional variant when we can resolve it during hir lowering instead.

ChayimFriedman2 · 2026-07-28T19:08:11Z

        &mut self,
        node: ast::Type,
        impl_trait_lower_fn: ImplTraitLowerFn<'_>,
+        lifetime_elision_fn: LifetimeElisionFn<'_>,


I'm not pleased with passing another callback everywhere. I would prefer an enum field saying what to do: an error, a 'static lifetime (for const and static types), a specific lifetime, or a new anonymous lifetime. In fact you can look at the old LifetimeElisionKind, which implements this (but only for diagnostics) and was copied from rustc.

I would anyways need access to lifetime Arena in GenericParamCollector.

What do you mean?

The callback works by pushing a '_ and using that Idx to create the LifetimeParamId.

So? Why can't this be done via an enum field?

You mean to say use a mutable reference of the arena inside one of enum variant.

I don't understand what you mean.

What I'm proposing is, instead of accepting a callback for what to do when encountering an elided lifetime, keep a field lifetime_elision_kind of type LifetimeElisionKind in ExpressionStore, similar to (in fact replacing) LifetimeElisionKind in TyLoweringContext, and act according to it.

The primary purpose of it being a callback here is to have a mutable access to the lifetime arena, but otherwise, I can indeed do what you suggest.

Hmm, I think it will be better if the enum LifetimeElisionKind will have a variant AsLifetimeParam { collector: &mut GenericParamsCollector, ... }. This does mean introducing another lifetime to ExprCollector, but that's not so bad.

Yeah, I can do that. Let me do it along with some other review comments over the weekend..

ChayimFriedman2 · 2026-07-28T19:09:33Z

+                            {
+                                TypeBound::ForLifetime(binder, path)
+                            } else {
+                                TypeBound::Path(path, m)


Do we even need TypeBound::Path now? After all in rustc_type_ir every predicate has a binder. We could just always produce ForLifetime.

internal: implement lifetime elision

7dfa685

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

fix: tests updated for lifetime ellision

88e02b3

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

	pub struct HrtbLifetimeParamId(pub usize);
	pub struct HrtbLifetimeParamId(pub u32);

-            LifetimeRef::HrtbParam(_) => None, // this should be unreachable, should we panic?
+            LifetimeRef::HrtbParam(_) => {
+                never!();
+                None
+            }

		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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dfireBird 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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dfireBird Jul 29, 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!

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!

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!

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!

Choose a reason for hiding this comment

ShoyuVanilla commented Jul 27, 2026 •

edited

Loading

Veykril left a comment •

edited by rustbot

Loading

dfireBird Jul 27, 2026 •

edited

Loading

ChayimFriedman2 left a comment •

edited by rustbot

Loading

dfireBird Jul 29, 2026 •

edited

Loading