Suggest adding undeclared lifetime parameters to struct

[cramertj]

The following code:

struct Foo {
    x: &'a u8,
}

Generates this error:

error[E0261]: use of undeclared lifetime name `'a`
 --> src/main.rs:2:9
  |
2 |     x: &'a u8,
  |         ^^ undeclared lifetime

error: aborting due to previous error

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

It'd be nice to provide a suggestion to add a lifetime parameter to the struct definition.

Originally suggested here.

[estebank]

In the following code:

rust/src/librustc/middle/resolve_lifetime.rs

Lines 1096 to 1099 in 5a2465e

	struct_span_err!(self.sess, lifetime_ref.span, E0261,
	"use of undeclared lifetime name `{}`", lifetime_ref.name.name())
	.span_label(lifetime_ref.span, "undeclared lifetime")
	.emit();

suggest adding the undeclared lifetime to the appropriate parent scope(s) (fn or impl blocks).

Bonus points to perform fuzzy search of the undeclared lifetime against all the parent binders to provide typo suggestion.

[typesanitizer]

I can work on this. :)

[estebank]

@theindigamer feel free to reach out in gitter, internals, IRC or here if you need any help!

[typesanitizer]

Thinking about using lifetime parameters that haven't been initialized generically (as opposed to purely in the context of struct definitions), the two simplest cases are

1. If inside a struct definition, suggest adding the lifetime parameter after the struct's name.
2. If inside a free-standing function, suggest adding the lifetime parameter after the function's name.

A slightly more complex case is:

3. If inside a function inside an impl, depending on the situation, add the lifetime parameter after the function's name or after the impl... - I'm not sure what heuristic should be used here for the suggestion. It might make more sense to either add the parameter to either the fn or to the impl.

One could create more complicated cases by arbitrarily nesting fn and impl (a fn can contain a struct and an impl, and an impl can contain a fn). I'm not entirely sure if we could cook up a case where the lifetime must be introduced in some arbitrary ancestor (not just the parent or grandparent), but maybe that is just my lack of imagination.

Another minor issue is that (ideally) we should "unify" errors in the sense that

impl Foo<'a> {
    fn x(&self) -> &'a u8
}

will give two errors

error[E0261]: use of undeclared lifetime name `'a`
 --> foo.rs:5:10
  |
5 | impl Foo<'a> {
  |          ^^ undeclared lifetime

error[E0261]: use of undeclared lifetime name `'a`
 --> foo.rs:6:21
  |
6 |     fn x(&self) -> &'a str { self.x }
  |                     ^^ undeclared lifetime

error: aborting due to 2 previous errors

but it should give only one suggestion, which is replace impl with impl<'a>. What would be a good approach for doing so?

[estebank]

You have adequately expressed the nuance when encountering nested scopes.

For the case where you have nested impls/fns/structs I would provide a label to all the places where the lifetime could be declared:

struct X;

impl X {
    fn bar(bar_arg: &'a usize) {
        fn foo(foo_arg: &'a usize) {
            struct Y {
                y: &'a usize,
            }
        }
    }
}

error[E0261]: use of undeclared lifetime name `'a`
 --> src/main.rs:4:22
  |
3 | impl X {
  | ------ if you mean to declare lifetime `'a` in the `impl`, use `impl<'a> X<'a>`
4 |     fn bar(bar_arg: &'a usize) {
  |     ------           ^^ undeclared lifetime
  |     |
  |     if you meant to declare lifetime `'a` in the `fn`, use `fn bar<'a>`

error[E0261]: use of undeclared lifetime name `'a`
 --> src/main.rs:5:26
  |
5 |         fn foo(foo_arg: &'a usize) {
  |            ---              ^^ undeclared lifetime
  |            |
  |            help: declare lifetime `'a`: `foo<'a>`

error[E0261]: use of undeclared lifetime name `'a`
 --> src/main.rs:7:21
  |
6 |            struct Y {
  |                   - help: declare lifetime `'a`: `Y<'a>`
7 |                 y: &'a usize,
  |                     ^^ undeclared lifetime

error: aborting due to 3 previous errors

For the code example you provided, what I would do is to still emit the first error, recommend the suggestion to add the undeclared lifetime to the impl but accept it at the parser level as a valid lifetime binding. This way the second error won't be emitted (unless the 'a binding is removed, then it will trigger), but the compilation won't be successful due to the first error. In the end the output would look something like:

error[E0261]: use of undeclared lifetime name `'a`
 --> foo.rs:5:10
  |
5 | impl Foo<'a> {
  | ----     ^^ undeclared lifetime
  | |
  | help: declare lifetime `'a` here: `impl<'a>`

[typesanitizer]

| ------ if you mean to declare lifetime 'a in the impl, use `impl<'a> X<'a>

Do you mean impl<'a> X here, since X doesn't have a lifetime parameter in the example? Also, I'm slightly surprised that you need to declare the lifetime in 3 places and (for example) this doesn't compile.

struct X;

impl<'a> X {
    fn bar(bar_arg: &'a usize) {
        fn foo(foo_arg: &'a usize) {
            struct Y<'a> {
                y: &'a usize,
            }
        }
    }
}

fn main() {}

Are lifetimes parameters only allowed to be used in the children and not in further descendants? That makes things much simpler.

accept it at the parser level as a valid lifetime binding

Got it. Just to make sure that I'm understanding correctly, the way to do it would be to call self.insert_lifetime with the appropriate arguments, correct?

[estebank]

Do you mean impl<'a> X here, since X doesn't have a lifetime parameter in the example?
You're right.

Are lifetimes parameters only allowed to be used in the children and not in further descendants? That makes things much simpler.

I believe lifetimes only get passed from impls to a nested fns, but not from an fn to a nested one or between nested impls.

Just to make sure that I'm understanding correctly, the way to do it would be to call self.insert_lifetime with the appropriate arguments, correct?

I believe that is the case.

[steveklabnik]

Triage: this error is the same today.

[estebank]

I believe #68267 partially addresses this.

Edit: confirmed that that PR addresses this case.