-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Support lifetime suggestion for method #13164
Conversation
@nikomatsakis: r? |
@ktt3ja it's generally good practice to have a longer commit message (e.g. describing the change you described in your comment). :) |
@huonw: I modified my comment a bit and moved it to the commit and PR messages. |
//~^ NOTE: consider using an explicit lifetime parameter as shown: fn baz2<'b>(&self, x: &'b int) -> (&'a int, &'b int) | ||
(self.bar, x) //~ ERROR: cannot infer | ||
//~^ ERROR: mismatched types | ||
//~^ ERROR: mismatched types |
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.
ugh, looks like test failed because I missed a ^
. I will put it in there tomorrow...
@nikomatsakis: r? |
r+ |
This includes a change to the way lifetime names are generated. Say we figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead of just generating a new lifetime `'c` like before to replace them, we would reuse `'a`. This is done so that when the lifetime name comes from an impl, we don't give something that's completely off, and we don't have to do much work to figure out where the name came from. For example, for the following code snippet: ```rust struct Baz<'x> { bar: &'x int } impl<'x> Baz<'x> { fn baz1(&self) -> &int { self.bar } } ``` `[rust-lang#1, 'x]` (where `rust-lang#1` is BrAnon(1) and refers to lifetime of `&int`) have to be marked the same lifetime. With the old method, we would generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int` or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
@nikomatsakis: PR got stale so I just rebased it. |
…sakis This includes a change to the way lifetime names are generated. Say we figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead of just generating a new lifetime `'c` like before to replace them, we would reuse `'a`. This is done so that when the lifetime name comes from an impl, we don't give something that's completely off, and we don't have to do much work to figure out where the name came from. For example, for the following code snippet: ```rust struct Baz<'x> { bar: &'x int } impl<'x> Baz<'x> { fn baz1(&self) -> &int { self.bar } } ``` `[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`) have to be marked the same lifetime. With the old method, we would generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int` or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
Bump ui_test version -> 0.25 r? `@Alexendoo` cc `@GuillaumeGomez` changelog: none
This includes a change to the way lifetime names are generated. Say we
figure that
[#0, 'a, 'b]
have to be the same lifetimes, then insteadof just generating a new lifetime
'c
like before to replace them, wewould reuse
'a
. This is done so that when the lifetime name comesfrom an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:
[#1, 'x]
(where#1
is BrAnon(1) and refers to lifetime of&int
)have to be marked the same lifetime. With the old method, we would
generate a new lifetime
'a
and suggestfn baz1(&self) -> &'a int
or
fn baz1<'a>(&self) -> &'a int
, both of which are wrong.