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: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: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-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?

Maybe instead of having multiple callback factories, we can have that a state in ExprCollector and based on which a the callback (so a single callback factory) returns appropriate LifetimeRef?

You can borrow just the parts you need, like you do for a callback.

I don't think it would work as well, only when lowering functions, because it would be borrowed mutably twice, once when I borrow it for the Arena and the other when it borrows for collect_impl_trait.

It might work in other places tho.

Closures borrow only the fields they use since edition 2024. If they wouldn't the code using callbacks wouldn't compile either.

I found a way to work around it, without callbacks, took a lot of trial and error to get the borrow checker right 😅

Now to implement it and see if it doesn't panic anywhere.

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.

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?

minor fixes related to review comments

rustbot · 2026-08-04T02:39:40Z

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.

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.

Veykril · 2026-08-04T09:47:51Z

+        (def, is_trait_assoc_item)
+    };
+
+    if collector.argument_elision_context.is_some() && !is_trait_assoc_item {


I think this branch means means omitted lifetime arguments are materialized only while lowering parameters. with_param_lt_elision restores argument_elision_context before the return type is lowered, so a signature like:

struct Wrapper<'a>(&'a str); fn wrap(value: &str) -> Wrapper;

creates a lifetime for value, but does not add the selected lifetime to the return Wrapper.

View changes since the review

I think we can change that branch to match the new lifetime_elision_kind instead, i.e if it's Static or Error don't call that function?

Veykril · 2026-08-04T10:06:33Z

    pub(in crate::expr_store) fn lower_generic_args_from_fn_path(
        &mut self,
        args: Option<ast::ParenthesizedArgList>,
        ret_type: Option<ast::RetType>,
        impl_trait_lower_fn: ImplTraitLowerFn<'_>,
    ) -> Option<GenericArgs> {
        let params = args?;
        let mut param_types = Vec::new();
        for param in params.type_args() {
            let type_ref = self.lower_type_ref_opt(param.ty(), impl_trait_lower_fn);
            param_types.push(type_ref);
        }
        let args = Box::new([GenericArg::Type(
            self.alloc_type_ref_desugared(TypeRef::Tuple(ThinVec::from_iter(param_types))),
        )]);
        let bindings = if let Some(ret_type) = ret_type {
            let type_ref = self.lower_type_ref_opt(ret_type.ty(), impl_trait_lower_fn);
            Box::new([AssociatedTypeBinding {
                name: Name::new_symbol_root(sym::Output),
                args: None,
                type_ref: Some(type_ref),
                bounds: Box::default(),
            }])
        } else {
            // -> ()
            let type_ref = self.alloc_type_ref_desugared(TypeRef::unit());
            Box::new([AssociatedTypeBinding {
                name: Name::new_symbol_root(sym::Output),
                args: None,
                type_ref: Some(type_ref),
                bounds: Box::default(),
            }])
        };
        Some(GenericArgs {
            args,
            has_self_type: false,
            bindings,
            parenthesized: GenericArgsParentheses::ParenSugar,
        })
    }


Parenthesized Fn syntax needs its own lifetime-elision state, like the FnPtrType branch.

type Callback = dyn Fn(&str) -> &str;

This should lower as dyn for<'a> Fn(&'a str) -> &'a str.

In a function parameter its a bit different as well:

fn run(callback: &dyn Fn(&str) -> &str) -> &dyn Fn(&str) -> &str;

should lower to

fn run<'p>( callback: &'p dyn for<'a> Fn(&'a str) -> &'a str, ) -> &'p dyn for<'b> Fn(&'b str) -> &'b str;

View changes since the review

Oof, I was reminding myself to do it, only to forget it :D

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 added 4 commits August 4, 2026 08:05

internal: implement lifetime elision

54ecc5b

fix: tests updated for lifetime ellision

711812c

fix: hide elided lifetimes in references and generic param list

9ffa4fb

minor fixes related to review comments

refactor: change elision callbacks to internal state

6526ecd

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

Veykril reviewed Aug 4, 2026

View reviewed changes

		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!

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!

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!

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!

dfireBird Aug 2, 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!

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

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 Aug 2, 2026 •

edited

Loading

Veykril Aug 4, 2026 •

edited by rustbot

Loading

Veykril Aug 4, 2026 •

edited by rustbot

Loading

dfireBird Aug 4, 2026 •

edited

Loading

Veykril Aug 4, 2026 •

edited by rustbot

Loading

dfireBird Aug 4, 2026 •

edited

Loading