| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately,
it could have been something like "syntax group" or "syntax
category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is
occurring, instead of trying to be general. A new `help` line is
general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also
changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't
occur in that specific suggestion.
|
|
|
|
|
|
|
|
|
|
|
|
This makes a small change as requested in code review, such that if there's
ambiguity in the self lifetime, we avoid lifetime elision entirely instead of
considering using lifetimes from any of the other parameters.
For example,
impl Something {
fn method(self: &Box<&Self>, something_else: &u32) -> &u32 { ... }
}
in standard Rust would have assumed the return lifetime was that of &Self;
with this PR prior to this commit would have chosen the lifetime of
'something_else', and after this commit would give an error message explaining
that the lifetime is ambiguous.
|
|
struct Concrete(u32);
impl Concrete {
fn m(self: &Box<Self>) -> &u32 {
&self.0
}
}
resulted in a confusing error.
impl Concrete {
fn n(self: &Box<&Self>) -> &u32 {
&self.0
}
}
resulted in no error or warning, despite apparent ambiguity over the elided
lifetime.
This commit changes two aspects of the behavior.
Previously, when examining the self type, we considered lifetimes only if they
were immediately adjacent to Self. We now consider lifetimes anywhere in the
self type.
Secondly, if more than one lifetime is discovered in the self type, we
disregard it as a possible lifetime elision candidate.
This is a compatibility break, and in fact has required some changes to tests
which assumed the earlier behavior.
Fixes https://github.com/rust-lang/rust/issues/117715
|
|
Do not suggest constraining the `&self` param, but rather the return type.
If that is wrong (because it is not sufficient), a follow up error will tell the
user to fix it. This way we lower the chances of *over* constraining, but still
get the cake of "correctly" contrained in two steps.
This is a correct suggestion:
```
error: lifetime may not live long enough
--> $DIR/ex3-both-anon-regions-return-type-is-anon.rs:9:9
|
LL | fn foo<'a>(&self, x: &i32) -> &i32 {
| - - let's call the lifetime of this reference `'1`
| |
| let's call the lifetime of this reference `'2`
LL | x
| ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
|
help: consider introducing a named lifetime parameter and update trait if needed
|
LL | fn foo<'a>(&self, x: &'a i32) -> &'a i32 {
| ++ ++
```
While this is incomplete because it should suggestino `&'a self`
```
error: lifetime may not live long enough
--> $DIR/ex3-both-anon-regions-self-is-anon.rs:7:19
|
LL | fn foo<'a>(&self, x: &Foo) -> &Foo {
| - - let's call the lifetime of this reference `'1`
| |
| let's call the lifetime of this reference `'2`
LL | if true { x } else { self }
| ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
|
help: consider introducing a named lifetime parameter and update trait if needed
|
LL | fn foo<'a>(&self, x: &'a Foo) -> &'a Foo {
| ++ ++
```
but the follow up error is
```
error: lifetime may not live long enough
--> tests/ui/lifetimes/lifetime-errors/ex3-both-anon-regions-self-is-anon.rs:7:30
|
6 | fn foo<'a>(&self, x: &'a Foo) -> &'a Foo {
| -- - let's call the lifetime of this reference `'1`
| |
| lifetime `'a` defined here
7 | if true { x } else { self }
| ^^^^ method was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1`
|
help: consider introducing a named lifetime parameter and update trait if needed
|
6 | fn foo<'a>(&'a self, x: &'a Foo) -> &'a Foo {
| ++
```
|
|
|
|
`run-rustfix`
```
error: lifetime may not live long enough
--> $DIR/lt-ref-self.rs:12:9
|
LL | fn ref_self(&self, f: &u32) -> &u32 {
| - - let's call the lifetime of this reference `'1`
| |
| let's call the lifetime of this reference `'2`
LL | f
| ^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
|
help: consider introducing a named lifetime parameter and update trait if needed
|
LL | fn ref_self<'b>(&'b self, f: &'b u32) -> &'b u32 {
| ++++ ++ ++ ++
```
|
|
```
error: lifetime may not live long enough
--> f205.rs:8:16
|
7 | fn resolve_symbolic_reference(&self, reference: Option<Reference>) -> Option<Reference> {
| - --------- has type `Option<Reference<'1>>`
| |
| let's call the lifetime of this reference `'2`
8 | return reference;
| ^^^^^^^^^ method was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
|
help: consider introducing a named lifetime parameter
|
7 | fn resolve_symbolic_reference<'a>(&'a self, reference: Option<Reference<'a>>) -> Option<Reference<'a>> {
| ++++ ++ ++++ ++++
```
The correct suggestion would be
```
help: consider introducing a named lifetime parameter
|
7 | fn resolve_symbolic_reference<'a>(&self, reference: Option<Reference<'a>>) -> Option<Reference<'a>> {
| ++++ ++++ ++++
```
but we are not doing the analysis to detect that yet. If we constrain `&'a self`, then the return type with a borrow will implicitly take its lifetime from `'a`, it is better to make it explicit in the suggestion, in case that `&self` *doesn't* need to be `'a`, but the return does.
|
|
|
|
|
|
When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix #85843.
|
|
|
|
|
|
|
