Skip to content

Suggesting adding lifetime to return type #94492

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kckeiks opened this issue Mar 1, 2022 · 4 comments
Closed

Suggesting adding lifetime to return type #94492

kckeiks opened this issue Mar 1, 2022 · 4 comments
Labels
A-borrow-checker Area: The borrow checker A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kckeiks
Copy link
Contributor

kckeiks commented Mar 1, 2022

When there is a (elided) lifetime mismatch, we output a hint to introduce a lifetime but the hint does not suggest adding a lifetime to the return type.

Given the following code:

trait T {
    fn foo(&self, x: &i32) -> Option<&i32> {
        Some(x)
    }
}

The current output is:



error[E0623]: lifetime mismatch
  --> src/main.rs:11:9
   |
10 |     fn foo(&self, x: &i32) -> Option<&i32> {
   |                      ----     ------------
   |                      |
   |                      this parameter and the return type are declared with different lifetimes...
11 |         Some(x)
   |         ^^^^^^^ ...but data from `x` is returned here
   |
   = note: each elided lifetime in input position becomes a distinct lifetime
help: consider introducing a named lifetime parameter
   |
10 |     fn foo<'a>(&'a self, x: &'a i32) -> Option<&i32> {
   |           ++++  ++           ++

error: aborting due to previous error

For more information about this error, try `rustc --explain E0623`.


Ideally the output should also suggest adding 'a to the return type:


error[E0623]: lifetime mismatch
  --> src/main.rs:11:9
   |
10 |     fn foo(&self, x: &i32) -> Option<&i32> {
   |                      ----     ------------
   |                      |
   |                      this parameter and the return type are declared with different lifetimes...
11 |         Some(x)
   |         ^^^^^^^ ...but data from `x` is returned here
   |
   = note: each elided lifetime in input position becomes a distinct lifetime
help: consider introducing a named lifetime parameter
   |
10 |     fn foo<'a>(&'a self, x: &'a i32) -> Option<&'a i32> {
   |           ++++  ++           ++                 ++

error: aborting due to previous error

For more information about this error, try `rustc --explain E0623`.

@kckeiks kckeiks added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 1, 2022
@kckeiks
Copy link
Contributor Author

kckeiks commented Mar 1, 2022

The diagnosis error shown in the issue description is created by the type NiceRegionError.
There is another type, LifetimeContext, that displays a better hint for similar code:

fn foo(x: &i32, y: &i32) -> Option<&i32> {
    Some(y)
}

Output:


error[E0106]: missing lifetime specifier
 --> src/main.rs:1:36
  |
1 | fn foo(x: &i32, y: &i32) -> Option<&i32> {
  |           ----     ----            ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
  |
1 | fn foo<'a>(x: &'a i32, y: &'a i32) -> Option<&'a i32> {
  |       ++++     ++          ++                 ++

error: aborting due to previous error

For more information about this error, try `rustc --explain E0106`.

These types have different information about the code, for example, LifetimeContext has span info for all parameters in function so it can produce a nice suggestion but NiceRegionError has "region" information which I think limits the quality of the hint it can produce. It would be great if hints produced could be more consistent regardless of where in the analysis step they're being generated from.

@kckeiks
Copy link
Contributor Author

kckeiks commented Mar 1, 2022

@rustbot label P-low

@rustbot
Copy link
Collaborator

rustbot commented Mar 1, 2022

Error: Label P-low can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

@estebank estebank added P-low Low priority A-borrow-checker Area: The borrow checker A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` labels Mar 1, 2022
@Dylan-DPC
Copy link
Member

This is now resolved and shows the lifetime in the return type in the suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-borrow-checker Area: The borrow checker A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants