-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls. #94464
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,12 @@ LL | fn a(self: Pin<&Foo>, f: &Foo) -> &Foo { f } | |
| ---- ---- ^ ...but data from `f` is returned here | ||
| | | ||
| this parameter and the return type are declared with different lifetimes... | ||
| | ||
= note: each elided lifetime in input position becomes a distinct lifetime | ||
help: consider introducing a named lifetime parameter | ||
| | ||
LL | fn a<'a>(self: Pin<&'a Foo>, f: &'a Foo) -> &Foo { f } | ||
| ++++ ++ ++ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm somewhat surprised by the suggestions I'm seeing that we don't also suggest adding There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you want me to add a comment about that note? I'm not 100% sure it's a bug. Seems like the code that added the hint did not take into consideration return types. To be fair though, AFAICT the diagnosis in this module is implemented very differently than what is in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's just create a targeted ticket for this instead of leaving it in the code. It'd be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
error[E0623]: lifetime mismatch | ||
--> $DIR/arbitrary_self_types_pin_lifetime_mismatch.rs:8:76 | ||
|
@@ -13,6 +19,12 @@ LL | fn c(self: Pin<&Self>, f: &Foo, g: &Foo) -> (Pin<&Foo>, &Foo) { (self, | |
| ---- ----------------- ^ ...but data from `f` is returned here | ||
| | | ||
| this parameter and the return type are declared with different lifetimes... | ||
| | ||
= note: each elided lifetime in input position becomes a distinct lifetime | ||
help: consider introducing a named lifetime parameter | ||
| | ||
LL | fn c<'a>(self: Pin<&'a Self>, f: &'a Foo, g: &Foo) -> (Pin<&Foo>, &Foo) { (self, f) } | ||
| ++++ ++ ++ | ||
|
||
error[E0623]: lifetime mismatch | ||
--> $DIR/arbitrary_self_types_pin_lifetime_mismatch.rs:13:58 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should handle the
impl
case specifically with extra wording in the suggestion to let people know that they'll have to modify thetrait
as well. This is likely not a problem in practice, but I'd like us to be thorough and avoid confusing people.It might be enough to just have a boolean flag that you use to modify the suggestion description with extra wording.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. I'll make that change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this for
impl
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would have something like "consider introducing a named lifetime parameter and update trait
TraitName
as necessary", by getting theTraitName
from the parent DefId, but that can be left as follow up work.