Implement underscore lifetimes

[cramertj]

Part of #44524

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[cramertj]

Feel free to bikeshed this error message (it shows up in code that tries to explicitly bind '_ in the generics of an item declaration).

[petrochenkov]

An equivalent error is already issued for 'static, so the wording can be reused:

invalid lifetime parameter name: `'static`

[arielb1]

r? @eddyb

[kennytm]

Should be 1.22.0? (BTW match_beginning_vert should also be 1.22.0?)

[eddyb]

I never know what to actually put here.

[eddyb]

r=me with build & nit fixed

[petrochenkov]

Lifetime definitions can happen in for<'a, 'b, 'c> in fn pointers, trait objects, etc.
It's better to place the error in fn visit_lifetime_def.

[petrochenkov]

@cramertj
What happens when '_ is written in some place where elided lifetimes are not supported currently?
For example bounds 'a: '_ + 'b, impl headers, struct definitions.
Could you add tests for these cases?

[nikomatsakis]

So I've never been crazy about using a "sentinel value" here rather than an enum -- now that we've got more than one sentinel, I feel even less good. Can't we change this to something like

enum LifetimeName {
    Elided,
    Underscore,
    Static,
    Name(Token) // or whatever this is
}

[eddyb]

It's a Symbol / ast::Name I think.

[nikomatsakis]

...if we were using an enum, this code would be rather cleaner

[nikomatsakis]

can we have some tests that use multiple lifetime parameters in one function? For example:

fn foo(x: &'_ u8, y: &'_ u8) -> &'_ u8 { } // ERROR from elision

fn foo(x: &mut Vec<&'_ u8>, y: &'_ u8) { x.push(y); // ERROR }

struct Foo<'a, 'b> { a: &'a u32, b: &'b u32 }
fn foo_a<'b>(foo: Foo<'_, 'b>) -> &'b u32 { &foo.a } // ERROR
fn foo_b<'b>(foo: Foo<'_, 'b>) -> &'b u32 { &foo.b } // OK

[nikomatsakis]

@cramertj thanks for jumping on this btw -- so excited to see it land =)

[petrochenkov]

Nooooo.
This LifetimeName over Name is pure over-engineering, N extra lines of boilerplate just to avoid one string comparison.

[cramertj]

Heh. I don't have any strong opinion here. Take it up with @nikomatsakis 😄
I left it as its own commit so it's easy to pull out if that's the decision.

[petrochenkov]

I'd better turn '_ into a weak keyword.

[nikomatsakis]

I disagree. Sentinel values mean you wind up with if-else-if chains like if foo.is_elided() { ... } which are easily forgotten. Having an enum means we can use exhaustive matching, so that when we add variants in the future, the compiler helps us catch cases that are missing etc.

Plus, there isn't a lot of boilerplate here.

[petrochenkov]

@nikomatsakis
Ok, not a big deal.
(I'll revert this when you are on vacation, ha-ha.)

[cramertj]

Gah! I didn't try building rustdoc and the others...

[eddyb]

cc @Mark-Simulacrum this is why I have rustbuild in my build setup.

[petrochenkov]

Symbol::intern("'static") => keywords::StaticLifetime.name()

[petrochenkov]

@cramertj
Could you add tests for '_ in impl headers and struct definitions? (But not as bounds or lifetime definitions.)

[bors]

☔️ The latest upstream changes (presumably #44551) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

@cramertj
Actually, can you tweak the naming slightly.

enum LifetimeKind { // This is not a name
    Implicit, // `Elided` is not correct, because implicit can be both elided and inferred, but we don't discern between them yet when lowering into HIR
    Underscore,
    Static,
    Named(Name), // Named lifetime
}

[petrochenkov]

(The variants are going to change anyway when lifetimes are first resolved, then lowered into HIR.)

[eddyb]

I think what we want is name resolution to give us a Def, and the existing resolve_lifetimes pass to do elision and compute the semantic representation from Def::Lifetime(DefId).

[nikomatsakis]

@petrochenkov I don't object to calling "Implicit" for sure, but I'm curious: what does "elided" mean to you? To me, it means "not written". I would then say that the behavior around elided lifetimes depends on context: in function signatures, we use defaulting rules (as specified by the lifetime elision RFCs plus the object-lifetime RFCs), and in function bodies, we use inference.

[eddyb]

Using "elided" to mean literally "not written" may be correct wrt the English language but then "elision rules" doesn't mean much anymore and we have to say "default lifetime rules" I guess? And "lifetime defaulting" for the process of picking a lifetime.

[nikomatsakis]

So personally, when I explain to people, I say something like "sometimes you can elide lifetimes. The meaning of this depends on context. In a function signature, we use the following system of defaults. etc". In other words, I think I do use the terms the way you described. =) But also I rely on context. That is, I might say "elision rules" when it's clear we're talking about function signatures, in which case it just means "defaulting rules" (but including, naturally, the object defaults).

In any case, it seems clear that calling things elided is ripe for confusion. I prefer either "implicit", "not written", or "not present", all of which seem reasonably clear.

[petrochenkov]

@nikomatsakis
Well, I usually associate "elided" with "lifetime elision RFCs", i.e. "defaulting", not inference.
It's useful to have some separate words for "not-written-in-signature" and "not-written-in-body", and "elided" and "inferred" already kinda serve this purpose given that "lifetime elision" is commonly used to describe what happens in signatures.

[nikomatsakis]

That makes some sense. I guess I prefer to have words that match their English meanings to the extent possible, though, and to me "elided" just means "not written" (whereas "defaulted" seems more specific -- we assigned it a default value). I admit that the distinction between defaulted (based on some simple rules) and inferred (based on complex analysis) is a subtle one as well. =)

[nikomatsakis]

Regardless, the question at hand is whether to use elided here with the broader meaning, right? In which case, "Implicit" or "Not written" seems fine.

[nikomatsakis]

@bors r+

[bors]

📌 Commit f5505d1 has been approved by nikomatsakis

[bors]

⌛️ Testing commit f5505d1 with merge 3eb19bf...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 3eb19bf to master...