Repository navigation
Suggest Struct::<'_> instead of Self when lifetime does not match #101393
Description
Heads-up: PR 100976 probably fixes this but I still felt its own issue was warranted (and didn't find an existing one).
pub struct Path<'a> {
string: &'a mut String,
}
impl<'a> Path<'a> {
pub fn sub(&mut self) -> Path/*<'_>*/ {
Self {
string: self.string,
}
}
}The current output is:
error: lifetime may not live long enough
--> src/lib.rs:8:21
|
5 | impl<'a> Path<'a> {
| -- lifetime `'a` defined here
6 | pub fn sub(&mut self) -> Path/*<'_>*/ {
| - let's call the lifetime of this reference `'1`
7 | Self {
8 | string: self.string,
| ^^^^^^^^^^^ this usage requires that `'1` must outlive `'a`
Ideally the output should look like:
7 | Self {
| ^^^^ help: Consider replacing `Self` with `Path`
Programmers not-infrequently expect Self to act as a type constructor and not fully aliased type (including lifetimes). Using Path in this context infers the lifetime, whereas using Self make the lifetime exactly 'a.
Though I haven't included it in my example, consider also the case when Self is used as the return type.
Another recent URLO example which inspired this report.
The same error appears on stable, nightly, and beta. But see PR 100976 which may resolve this issue.
@rustbot label +A-lifetimes +A-suggestion-diagnostics +D-newcomer-roadblock
Reacted by Ali MJ Al-Nasrawy, León Orell Valerian Liehr, Chayim Refael Friedman, Brendan Zabarauskas, Maria Solano, Moises Marquez, Esteban Kuber, Robert Knight, Tristan Guichaoua, Johannes Dahlström and 2 more
Activity
MariaSolOs commentedon May 25, 2023
Bumping this! I recently encountered this error and it took me way too long to fix it.
estebank commentedon Sep 12, 2026
After #162701, the only outstanding work would be, in the example above, pointing at the
Pathreturn type to make it clear that it is influencing the lifetime requirements for the returned expression and that it has a lifetime that wasn't spelled out. This case has a lint already, but because there are type errors, it doesn't ever get evaluated, so it should be part of the borrow checker analysis as well (even if the lint triggered, emitting a single error instead of two is always ideal).Edit: addressed the above.