self: &Box<Self> produces confusing error due to failure to spot elided lifetime
#117715
Comments
adetaylor
added
A-diagnostics
rustbot
added
the
needs-triage
saethlin
added
A-lifetimes
|
Yeah that definitely seems wrong. Cc @rust-lang/types ? not sure who's in charge of lifetime elision |
|
Some analysis/proposals. How
|
That makes no sense to me. Elision treats the |
All the code I'm talking about is only ever applied to the |
|
Oh I see, thanks for clarifying. I would say we should check the entire type for lifetimes. I am still confused, though. We currently entirely ignore the outer lifetime of the argument. In So, this must be a breaking change anyway since |
|
In the case of I'll have a crack at option 1 and see what breaks in the unit tests. I'm sure I'll learn something! |
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.
Fixes rust-lang#117715
|
The sort of fix I think we need is something like this, however, it's not quite right yet and lots of the existing elision tests fail. Parking it here because I'm unlikely to get time to work on it for a few days at least. |
|
The simple option doesn't pass tests here due to a test called trait Trait {
type AssocType;
}
struct Struct { }
impl Trait for Struct {
type AssocType = Self;
}
impl Struct {
fn ref_AssocType(self: &<Struct as Trait>::AssocType, f: &u32) -> &u32 {
f
}
}(there are some other similar tests too) Previously, this worked because If we search the whole type hierarchy for So the question is, can we be sure that the There are also some (Again all this code only applies to the first parameter). |
|
IMO that test is clearly buggy, the lifetime of the return value is ambiguous. It should either fail because the lifetime is ambiguous or fail because it infers the We might want to do a transition here where we first warn that such code will be rejected in the future, before we start rejecting it. Would be good to get a crater run to tell us how common this pattern is. Cc @rust-lang/types for more input. |
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 rust-lang#117715
|
I agree that the current behavior of |
|
I've marked #117967 as ready for review. It goes with approach 1. |
…r=<try>
Fix lifetime elision
```rust
struct Concrete(u32);
impl Concrete {
fn m(self: &Box<Self>) -> &u32 {
&self.0
}
}
```
resulted in a confusing error.
```rust
impl Concrete {
fn n(self: &Box<&Self>) -> &u32 {
&self.0
}
}
```
resulted in no error or warning, despite apparent ambiguity over the elided lifetime.
Fixes rust-lang#117715
…r=<try>
Fix lifetime elision
```rust
struct Concrete(u32);
impl Concrete {
fn m(self: &Box<Self>) -> &u32 {
&self.0
}
}
```
resulted in a confusing error.
```rust
impl Concrete {
fn n(self: &Box<&Self>) -> &u32 {
&self.0
}
}
```
resulted in no error or warning, despite apparent ambiguity over the elided lifetime.
Fixes rust-lang#117715
…r=<try>
Fix ambiguous cases of multiple & in elided self lifetimes
```rust
struct Concrete(u32);
impl Concrete {
fn m(self: &Box<Self>) -> &u32 {
&self.0
}
}
```
resulted in a confusing error.
```rust
impl Concrete {
fn n(self: &Box<&Self>) -> &u32 {
&self.0
}
}
```
resulted in no error or warning, despite apparent ambiguity over the elided lifetime.
Fixes rust-lang#117715
…r=lcnr Fix ambiguous cases of multiple & in elided self lifetimes This change proposes simpler rules to identify the lifetime on `self` parameters which may be used to elide a return type lifetime. ## The old rules (copied from [this comment](rust-lang#117967 (comment))) Most of the code can be found in [late.rs](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html) and acts on AST types. The function [resolve_fn_params](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2006), in the success case, returns a single lifetime which can be used to elide the lifetime of return types. Here's how: * If the first parameter is called self then we search that parameter using "`self` search rules", below * If no unique applicable lifetime was found, search all other parameters using "regular parameter search rules", below (In practice the code does extra work to assemble good diagnostic information, so it's not quite laid out like the above.) ### `self` search rules This is primarily handled in [find_lifetime_for_self](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2118) , and is described slightly [here](rust-lang#117715 (comment)) already. The code: 1. Recursively walks the type of the `self` parameter (there's some complexity about resolving various special cases, but it's essentially just walking the type as far as I can see) 2. Each time we find a reference anywhere in the type, if the **direct** referent is `Self` (either spelled `Self` or by some alias resolution which I don't fully understand), then we'll add that to a set of candidate lifetimes 3. If there's exactly one such unique lifetime candidate found, we return this lifetime. ### Regular parameter search rules 1. Find all the lifetimes in each parameter, including implicit, explicit etc. 2. If there's exactly one parameter containing lifetimes, and if that parameter contains exactly one (unique) lifetime, *and if we didn't find a `self` lifetime parameter already*, we'll return this lifetime. ## The new rules There are no changes to the "regular parameter search rules" or to the overall flow, only to the `self` search rules which are now: 1. Recursively walks the type of the `self` parameter, searching for lifetimes of reference types whose referent **contains** `Self`.[^1] 2. Keep a record of: * Whether 0, 1 or n unique lifetimes are found on references encountered during the walk 4. If no lifetime was found, we don't return a lifetime. (This means other parameters' lifetimes may be used for return type lifetime elision). 5. If there's one lifetime found, we return the lifetime. 6. If multiple lifetimes were found, we abort elision entirely (other parameters' lifetimes won't be used). [^1]: this prevents us from considering lifetimes from inside of the self-type ## Examples that were accepted before and will now be rejected ```rust fn a(self: &Box<&Self>) -> &u32 fn b(self: &Pin<&mut Self>) -> &String fn c(self: &mut &Self) -> Option<&Self> fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg ``` ### Examples that change the elided lifetime ```rust fn e(self: &mut Box<Self>, arg: &usize) -> &usize // ^ new ^ previous ``` ## Examples that were rejected before and will now be accepted ```rust fn f(self: &Box<Self>) -> &u32 ``` --- *edit: old PR description:* ```rust struct Concrete(u32); impl Concrete { fn m(self: &Box<Self>) -> &u32 { &self.0 } } ``` resulted in a confusing error. ```rust impl Concrete { fn n(self: &Box<&Self>) -> &u32 { &self.0 } } ``` resulted in no error or warning, despite apparent ambiguity over the elided lifetime. Fixes rust-lang#117715
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 rust-lang#117715
Fix ambiguous cases of multiple & in elided self lifetimes This change proposes simpler rules to identify the lifetime on `self` parameters which may be used to elide a return type lifetime. ## The old rules (copied from [this comment](rust-lang/rust#117967 (comment))) Most of the code can be found in [late.rs](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html) and acts on AST types. The function [resolve_fn_params](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2006), in the success case, returns a single lifetime which can be used to elide the lifetime of return types. Here's how: * If the first parameter is called self then we search that parameter using "`self` search rules", below * If no unique applicable lifetime was found, search all other parameters using "regular parameter search rules", below (In practice the code does extra work to assemble good diagnostic information, so it's not quite laid out like the above.) ### `self` search rules This is primarily handled in [find_lifetime_for_self](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2118) , and is described slightly [here](rust-lang/rust#117715 (comment)) already. The code: 1. Recursively walks the type of the `self` parameter (there's some complexity about resolving various special cases, but it's essentially just walking the type as far as I can see) 2. Each time we find a reference anywhere in the type, if the **direct** referent is `Self` (either spelled `Self` or by some alias resolution which I don't fully understand), then we'll add that to a set of candidate lifetimes 3. If there's exactly one such unique lifetime candidate found, we return this lifetime. ### Regular parameter search rules 1. Find all the lifetimes in each parameter, including implicit, explicit etc. 2. If there's exactly one parameter containing lifetimes, and if that parameter contains exactly one (unique) lifetime, *and if we didn't find a `self` lifetime parameter already*, we'll return this lifetime. ## The new rules There are no changes to the "regular parameter search rules" or to the overall flow, only to the `self` search rules which are now: 1. Recursively walks the type of the `self` parameter, searching for lifetimes of reference types whose referent **contains** `Self`.[^1] 2. Keep a record of: * Whether 0, 1 or n unique lifetimes are found on references encountered during the walk 4. If no lifetime was found, we don't return a lifetime. (This means other parameters' lifetimes may be used for return type lifetime elision). 5. If there's one lifetime found, we return the lifetime. 6. If multiple lifetimes were found, we abort elision entirely (other parameters' lifetimes won't be used). [^1]: this prevents us from considering lifetimes from inside of the self-type ## Examples that were accepted before and will now be rejected ```rust fn a(self: &Box<&Self>) -> &u32 fn b(self: &Pin<&mut Self>) -> &String fn c(self: &mut &Self) -> Option<&Self> fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg ``` ### Examples that change the elided lifetime ```rust fn e(self: &mut Box<Self>, arg: &usize) -> &usize // ^ new ^ previous ``` ## Examples that were rejected before and will now be accepted ```rust fn f(self: &Box<Self>) -> &u32 ``` --- *edit: old PR description:* ```rust struct Concrete(u32); impl Concrete { fn m(self: &Box<Self>) -> &u32 { &self.0 } } ``` resulted in a confusing error. ```rust impl Concrete { fn n(self: &Box<&Self>) -> &u32 { &self.0 } } ``` resulted in no error or warning, despite apparent ambiguity over the elided lifetime. Fixes rust-lang/rust#117715
Fix ambiguous cases of multiple & in elided self lifetimes This change proposes simpler rules to identify the lifetime on `self` parameters which may be used to elide a return type lifetime. ## The old rules (copied from [this comment](rust-lang/rust#117967 (comment))) Most of the code can be found in [late.rs](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html) and acts on AST types. The function [resolve_fn_params](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2006), in the success case, returns a single lifetime which can be used to elide the lifetime of return types. Here's how: * If the first parameter is called self then we search that parameter using "`self` search rules", below * If no unique applicable lifetime was found, search all other parameters using "regular parameter search rules", below (In practice the code does extra work to assemble good diagnostic information, so it's not quite laid out like the above.) ### `self` search rules This is primarily handled in [find_lifetime_for_self](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2118) , and is described slightly [here](rust-lang/rust#117715 (comment)) already. The code: 1. Recursively walks the type of the `self` parameter (there's some complexity about resolving various special cases, but it's essentially just walking the type as far as I can see) 2. Each time we find a reference anywhere in the type, if the **direct** referent is `Self` (either spelled `Self` or by some alias resolution which I don't fully understand), then we'll add that to a set of candidate lifetimes 3. If there's exactly one such unique lifetime candidate found, we return this lifetime. ### Regular parameter search rules 1. Find all the lifetimes in each parameter, including implicit, explicit etc. 2. If there's exactly one parameter containing lifetimes, and if that parameter contains exactly one (unique) lifetime, *and if we didn't find a `self` lifetime parameter already*, we'll return this lifetime. ## The new rules There are no changes to the "regular parameter search rules" or to the overall flow, only to the `self` search rules which are now: 1. Recursively walks the type of the `self` parameter, searching for lifetimes of reference types whose referent **contains** `Self`.[^1] 2. Keep a record of: * Whether 0, 1 or n unique lifetimes are found on references encountered during the walk 4. If no lifetime was found, we don't return a lifetime. (This means other parameters' lifetimes may be used for return type lifetime elision). 5. If there's one lifetime found, we return the lifetime. 6. If multiple lifetimes were found, we abort elision entirely (other parameters' lifetimes won't be used). [^1]: this prevents us from considering lifetimes from inside of the self-type ## Examples that were accepted before and will now be rejected ```rust fn a(self: &Box<&Self>) -> &u32 fn b(self: &Pin<&mut Self>) -> &String fn c(self: &mut &Self) -> Option<&Self> fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg ``` ### Examples that change the elided lifetime ```rust fn e(self: &mut Box<Self>, arg: &usize) -> &usize // ^ new ^ previous ``` ## Examples that were rejected before and will now be accepted ```rust fn f(self: &Box<Self>) -> &u32 ``` --- *edit: old PR description:* ```rust struct Concrete(u32); impl Concrete { fn m(self: &Box<Self>) -> &u32 { &self.0 } } ``` resulted in a confusing error. ```rust impl Concrete { fn n(self: &Box<&Self>) -> &u32 { &self.0 } } ``` resulted in no error or warning, despite apparent ambiguity over the elided lifetime. Fixes rust-lang/rust#117715
Code
Current output
Desired output
Rationale and extra context
No response
Other cases
No response
Anything else?
results in an error where rustc assumes we're returning the
_otherparameter, which presumably results from the same failure to spot a lifetime attached toself.This issue was identified during discussion about a new Rust RFC, here.
I suspect this is caused by something within
find_lifetime_for_selfwhich isn't aware of the need to support things likeBoxas aselftype: I haven't spotted the bug yet, I thought it was more important to get it reported properly first.The text was updated successfully, but these errors were encountered: