Oddity with lifetime elision and type aliases

[traviscross]

In reviewing a test case for,

• Add a new mismatched-lifetime-syntaxes lint #138677
  • (Which is part of Split elided_lifetime_in_paths into tied and untied #120808.)

I was led to the following oddity:

pub struct W<'a>(&'a ());
pub type Alias<'a> = W<'a>;

impl<'a> Alias<'a> {
    fn f1<'x>(self: &W<'a>, x: &'x ()) -> &() { x } //~ `'_ == 'x`, what?
    fn f2<'x>(self: &Alias<'a>, x: &'x ()) -> &() { x } //~ `'_ == 'x`, what?
    fn f3<'x>(&self, _: &'x ()) -> &() { self.0 } //~ OK.
}

impl<'a> W<'a> {
    fn f4<'x>(self: &W<'a>, _: &'x ()) -> &() { self.0 } //~ OK.
    fn f5<'x>(self: &Alias<'a>, x: &'x ()) -> &() { x } //~ `'_ == 'x`, what?
    fn f6<'x>(&self, _: &'x ()) -> &() { self.0 } //~ OK.
}

Playground link

This was noticed long ago in #60944 (comment), which is presumably when the test case was added, but I can't immediately find later discussion.

The Reference doesn't document this behavior. (The FLS, as best I can tell on a skim, does not document lifetime elision at all.)

If there's a good reason for this as the correct behavior, we should probably write this down in the Reference. Otherwise, I'm going to propose we agree to try to do away with this somehow, if possible, maybe over an edition.

@rustbot labels +C-discussion +T-lang +I-lang-nominated +A-lifetimes

cc @rust-lang/lang @ehuss

[Veykril]

(The FLS, as best I can tell on a skim, does not document lifetime elision at all.)

It does, but it also does not capture this oddity I think: https://github.com/rust-lang/fls/blob/main/src/types-and-traits.rst#lifetime-elision

[traviscross]

Interestingly, rust-analyzer, when configured to show inlay lifetime hints, gets f1-f3 and f5-f6 correct (i.e. matches the behavior of rustc) but gets f4 wrong.

That is, it annotates it like this:

impl<'a> Alias<'a> {
    fn f1<'x>(self: &W<'a>, x: &'x ()) -> &'x () { x } //~ `'_ == 'x`, what?
    fn f2<'x>(self: &Alias<'a>, x: &'x ()) -> &'x () { x } //~ `'_ == 'x`, what?
    fn f3<'0, 'x>(&self, _: &'x ()) -> &'0 () { self.0 } //~ OK.
}

impl<'a> W<'a> {
    fn f4<'x>(self: &W<'a>, _: &'x ()) -> &'x () { self.0 } //~ Wrong r-a annotation.
    fn f5<'x>(self: &Alias<'a>, x: &'x ()) -> &'x () { x } //~ `'_ == 'x`, what?
    fn f6<'0, 'x>(&self, _: &'x ()) -> &'0 () { self.0 } //~ OK.
}

[Veykril]

Those inlay hints are entirely syntactically based and known to be wrong in some scenarios (r-a has not implemented semantic lifetime elision yet)

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. This seems emphatically like a bug. We should try to fix it, and do a crater run to see if fixing it breaks anything.

[apiraino]

We think that T-types is more fit to discuss this (I am at RustWeek with @Urgau 🙂 ) so:

@rustbot label -I-compiler-nominated +I-types-nominated

[compiler-errors]

This is two bugs:

(1.) Lifetime elision special-casing for self: &Ty only works for structs

rust/compiler/rustc_resolve/src/late.rs

Line 2512 in 2a5da7a

Res::Def(DefKind::Struct | DefKind::Union | DefKind::Enum, _,) | Res::PrimTy(_)

That is to say, we don't prefer the lifetime in self: &Alias even if we're in some impl Alias because we only prefer structs/unions/enums in this hack.

(2.) Lifetime elision special-casing does not look through type aliases

We prefer the lifetime in self: &Struct only in impl Struct, only considering syntactical equality between the impl self type and the type inside the reference.

rust/compiler/rustc_resolve/src/late.rs

Lines 2467 to 2473 in 2a5da7a

	TyKind::Path(None, _) => {
	let path_res = self.r.partial_res_map[&ty.id].full_res();
	if let Some(Res::SelfTyParam { .. } | Res::SelfTyAlias { .. }) = path_res {
	return true;
	}
	self.impl_self.is_some() && path_res == self.impl_self
	}

---

I believe (1.) could be easily tweaked to also consider aliases. That would fix:

pub struct W<'a>(&'a ());
pub type Alias<'a> = W<'a>;

impl<'a> Alias<'a> {
    fn f2<'x>(self: &Alias<'a>, x: &'x ()) -> &() { self.0 }
}

I don't believe (2.) could be fixed to look through aliases, though, since this lifetime elision happens pretty early in the compiler, and I'm not sure we have the information to look through type aliases yet.

---

I'm kinda unsure why we even support this partial "is self type" behavior. It's pretty inconsistent, i.e. we prefer the self lifetime if the self type matches the struct of the only shallowly i.e. W<i32> would match W<()> and prefer its lifetime in self: &W<i32>.

I think it would've only been nice to support lifetimes when users write self: &Self and not self: &Struct (when the impl self is Struct).

I didn't look for much justification in the following PRs, but maybe someone had thoughts there:

• Allow lifetime elision in arbitrary_self_types #60944
• Allow lifetime elision in Pin<&(mut) Self> #61207

[traviscross]

Thanks for those details and that analysis. In looking through #61207, I see there is this write-up by @nikomatsakis trying to document the then-current behavior:

https://gist.github.com/nikomatsakis/5996e4f58899ef5c6926948b6f76835e

[lcnr]

I agree with errs that fixing f2 seems quite doable. I also think that resolving aliases to their underlying type is difficult at the point where we handle lifetime elision.

I believe that we can future compat lint changes to our lifetime elision rules. So if we decide to only do the self-type lifetime elision if there's an actual Self in there, then we could keep the existing behavior with a FCW. I separately think that we may want to lint on self: X where X does not contain Self. I don't know the impact of this change so we'd probably need to crater run to get an estimate first

[lcnr]

Generally, I think lifetime elisions is one of the areas where there are a lot of not-nice edge-cases right now and no awesome solution is possible. I personally don't think we should spend too much of our time on it and should prioritize other things as a project. Though ofc individual contributor is more than welcome to dive into this regardless. I would still love this area to be cleaned up.