rustc: implement error messages from lifetime elision RFC

[aturon]

The new lifetime elision rules recently landed, but the error messages for the rules do not reflect the RFC. The function

fn test(s: &str, t: &str) -> &str {
    s
}

produces the error

elision.rs:1:30: 1:34 error: missing lifetime specifier [E0106]
elision.rs:1 fn test(s: &str, t: &str) -> &str {
                                          ^~~~

The error messages are critical for providing a gentle slope from the intuition of borrowing to the mechanism of lifetimes.

cc @pcwalton @nick29581

[alexcrichton]

Nominating.

[pnkfelix]

Assigning P-high, 1.0 milestone. (Its relatively high priority because the RFC was accepted in part because of the error message support it proclaimed.)

[nikomatsakis]

The test now produces the appropriate help:

<anon>:1:30: 1:34 error: missing lifetime specifier [E0106]
<anon>:1 fn test(s: &str, t: &str) -> &str {
                                      ^~~~
<anon>:1:34: 1:34 help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `s` or `t`

[pnkfelix]

some progress has been made on this.

some aspects of the RFC are not yet implemented.

I will audit to evaluate what's left to do here.

[pnkfelix]

Result of audit:

For the fn case, the RFC example was a little more elaborate than what we do today, in that it proposed also including the text (adapted to @nikomatsakis 's example):

this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from s or t. Mark the input parameter it borrows from using lifetimes, e.g. [generated example]. See [url] for an introduction to lifetimes.

where presumably [generated example] is meant to denote something like: fn test<'a>(s: &'a str, t: &str) -> &'a str, and [url] is meant to be a link to some docs.

I don't think these additional sentences are crucial. They certainly are not a 1.0 blocker.

---

For the impl case:

First off, the error scenario for the impl case was explicitly stated to be rare in the RFC itself. (But then again, a pattern that is rare today may become more prevalent in the future...)

Perhaps more importantly: As far as I can tell, the lifetime elision rules for the impl case do not actually appear to be implemented today. In particular, both of the following examples cause compiler errors today:

trait Foo<'a> { fn foo(&self) -> &'a u32; }
struct Bar0(&'static u32, &'static u32);
impl Foo for Bar0 { fn foo(&self) -> &u32 { self.0 } }
fn main() { }

playpen yields:

<anon>:3:6: 3:9 error: wrong number of lifetime parameters: expected 1, found 0 [E0107]
<anon>:3 impl Foo for Bar0 { fn foo(&self) -> &u32 { self.0 } }
              ^~~

And perhaps more importantly (in terms of a useful case where elision could well apply):

trait Foo<'a> { fn foo(&self) -> &'a u32; }
struct Bar1<'b>(&'b u32, &'b u32);
impl Foo for Bar1 { fn foo(&self) -> &u32 { self.0 } }
fn main() { }

playpen yields:

<anon>:3:14: 3:18 error: wrong number of lifetime parameters: expected 1, found 0 [E0107]
<anon>:3 impl Foo for Bar1 { fn foo(&self) -> &u32 { self.0 } }
                      ^~~~
<anon>:3:6: 3:9 error: wrong number of lifetime parameters: expected 1, found 0 [E0107]
<anon>:3 impl Foo for Bar1 { fn foo(&self) -> &u32 { self.0 } }
              ^~~
error: aborting due to 2 previous errors

So therefore it is not currently relevant how we handle the case below; it will just error due to the missing parameters, and so we need not yet worry about the "cliff" between the above two cases and this one.

trait Foo<'a> { fn foo(&self) -> &'a u32; }
struct Bar2<'b,'c>(&'b u32, &'c u32);
impl Foo for Bar2 { fn foo(&self) -> &u32 { self.0 } }
fn main() { }

playpen

[pnkfelix]

This is no longer a priority for 1.0 (see audit results above). Arguably the issue could be closed outright, depending on whether we have potentially decided to not actually implement lifetime elision for impl's after all...

Update: ah, we apparently are still intending to implement elision for impl's at some point, see #15872

[pnkfelix]

triage: P-low

[pnkfelix]

(unassigning from self since I did the audit promised above.)

[brson]

Just nominating this for re-triage. It was a critical part of the elision RFC, and still not implemented.

cc @jonathandturner @GuillaumeGomez important error messages need to get done.

[GuillaumeGomez]

@brson: Taking a look next week!

[nikomatsakis]

Closing in favor of #15872 -- the remaining work is about implementing elision for impls, not really about the error message.