Skip to content
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

cannot infer an appropriate lifetime for pattern should have fix suggestions #50195

Closed
hellow554 opened this issue Apr 24, 2018 · 12 comments · Fixed by #122213
Closed

cannot infer an appropriate lifetime for pattern should have fix suggestions #50195

hellow554 opened this issue Apr 24, 2018 · 12 comments · Fixed by #122213
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-verbose Diagnostics: Too much output caused by a single piece of incorrect code. P-medium Medium priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@hellow554
Copy link
Contributor

hellow554 commented Apr 24, 2018

While I love NLL, I see, that the error messages one gets are way too complicated.

Example:
Stable vs. Nightly

This question came up on SO and I find this very confusing to new people and if NLL lands in the next iteration of stable, I would suggest using the old recommendation.


(Update from pnkfelix: As discussed in comment thread, NLL is not relevant here. The given examples are not opting into using the feature.)

@oli-obk
Copy link
Contributor

oli-obk commented Apr 24, 2018

That seems like an unfortunate combination of NLL + the implicit pattern borrow feature.

stable reports

error[E0658]: non-reference pattern used to match a reference (see issue #42640)
 --> src/main.rs:5:39
  |
5 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |                                       ^^^^^^ help: consider using a reference: `&(_, v)`

while nightly reports some insane borrow error, because v is a reference and not a value taken out of a borrowed tuple. The implicit borrowing in patterns allows to match with (_, v) on a &(a, b) value, but it'll automatically turn v into a reference, which leads to the resulting borrow error.

Applying the suggestion from the stable compiler or alternatively dereferencing v fixes the issue.

@oli-obk oli-obk added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. regression-from-stable-to-beta Performance or correctness regression from stable to beta. labels Apr 24, 2018
@LukasKalbertodt
Copy link
Member

Does this even have anything to do with NLL? I think RFC 2005 match ergonomics is the only problematic new feature at play here.

@oli-obk
Copy link
Contributor

oli-obk commented Apr 24, 2018

Nope, not NLL related at all, you're right. Changing the offending line to

    let v = counts.iter().max_by_key(|&(_, ref v)| v);

emits the same error on stable and nightly. We should simply improve that error and ignore the match ergonomics change.

@oli-obk oli-obk changed the title NLL error get's too complicated cannot infer an appropriate lifetime for pattern should have fix suggestions Apr 24, 2018
@hellow554
Copy link
Contributor Author

Oops, I saw lifetime issues labeld with lifetime #2 and I thought at NLL, sorry for the false noise.

Thank you for clarification.

@pietroalbini pietroalbini added this to the 1.26 milestone Apr 26, 2018
@nikomatsakis
Copy link
Contributor

The root error here is that the region is escaping the closure -- I thought we had some other issue about this -- cc @estebank, do you remember? Anyway, I agree it'd be nice to do better here!

@estebank
Copy link
Contributor

@nikomatsakis if you're referring to the same case I'm recalling, it involved a closure attempting to mutate a captured binding, this case is about capturing one of its arguments. That being said, it probably is evaluated by the same code. I don't recall the ticket off the top of my head.

@pietroalbini
Copy link
Member

Ping @nikomatsakis @estebank! We're approaching the release of 1.26, do we want to get this regression fixed?

@estebank
Copy link
Contributor

estebank commented May 1, 2018

I'm a bit time constrained at the moment so I can't commit to get this solved before the next release :-/

@nikomatsakis
Copy link
Contributor

triage: P-medium

We've got a lot on our plates right now, so we're going to categorize this as P-medium. But I'm going to investigate and try to at least get some mentoring instructions up.

@pietroalbini pietroalbini added the P-medium Medium priority label May 3, 2018
@alexcrichton alexcrichton removed this from the 1.26 milestone May 7, 2018
@alexcrichton alexcrichton added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. and removed regression-from-stable-to-beta Performance or correctness regression from stable to beta. labels May 7, 2018
@estebank
Copy link
Contributor

estebank commented Aug 29, 2018

NLL makes the error better, albeit not ideal:

error: unsatisfied lifetime constraints
 --> src/main.rs:6:47
  |
6 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |                                       ------- ^ returning this value requires that `'1` must outlive `'2`
  |                                       |     |
  |                                       |     return type of closure is &'2 &i32
  |                                       has type `&'1 (&i32, &i32)`

Still no suggestion with or without NLL.

@XAMPPRocky XAMPPRocky added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Oct 2, 2018
@oli-obk
Copy link
Contributor

oli-obk commented May 24, 2019

Triage, current output:

error[E0495]: cannot infer an appropriate lifetime for pattern due to conflicting requirements
 --> src/main.rs:5:43
  |
5 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |                                           ^
  |
note: first, the lifetime cannot outlive the anonymous lifetime #2 defined on the body at 5:38...
 --> src/main.rs:5:38
  |
5 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |                                      ^^^^^^^^^^
note: ...so that reference does not outlive borrowed content
 --> src/main.rs:5:43
  |
5 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |                                           ^
note: but, the lifetime must be valid for the method call at 5:13...
 --> src/main.rs:5:13
  |
5 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...so that a type/lifetime parameter is in scope here
 --> src/main.rs:5:13
  |
5 |     let v = counts.iter().max_by_key(|(_, v)| v);
  |      

@estebank estebank added D-confusing Diagnostics: Confusing error or lint that should be reworked. D-verbose Diagnostics: Too much output caused by a single piece of incorrect code. labels Dec 20, 2019
@estebank
Copy link
Contributor

Triage: we now have the nll output.

estebank added a commit to estebank/rust that referenced this issue Mar 8, 2024
When encoutnering a case like

```rust
//@ run-rustfix
use std::collections::HashMap;

fn main() {
    let vs = vec![0, 0, 1, 1, 3, 4, 5, 6, 3, 3, 3];

    let mut counts = HashMap::new();
    for num in vs {
        let count = counts.entry(num).or_insert(0);
        *count += 1;
    }

    let _ = counts.iter().max_by_key(|(_, v)| v);
```
produce the following suggestion
```
error: lifetime may not live long enough
  --> $DIR/return-value-lifetime-error.rs:13:47
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| v);
   |                                       ------- ^ returning this value requires that `'1` must outlive `'2`
   |                                       |     |
   |                                       |     return type of closure is &'2 &i32
   |                                       has type `&'1 (&i32, &i32)`
   |
help: dereference the return value
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| **v);
   |                                               ++
```

Fix rust-lang#50195.
estebank added a commit to estebank/rust that referenced this issue Apr 4, 2024
When encoutnering a case like

```rust
//@ run-rustfix
use std::collections::HashMap;

fn main() {
    let vs = vec![0, 0, 1, 1, 3, 4, 5, 6, 3, 3, 3];

    let mut counts = HashMap::new();
    for num in vs {
        let count = counts.entry(num).or_insert(0);
        *count += 1;
    }

    let _ = counts.iter().max_by_key(|(_, v)| v);
```
produce the following suggestion
```
error: lifetime may not live long enough
  --> $DIR/return-value-lifetime-error.rs:13:47
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| v);
   |                                       ------- ^ returning this value requires that `'1` must outlive `'2`
   |                                       |     |
   |                                       |     return type of closure is &'2 &i32
   |                                       has type `&'1 (&i32, &i32)`
   |
help: dereference the return value
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| **v);
   |                                               ++
```

Fix rust-lang#50195.
estebank added a commit to estebank/rust that referenced this issue Apr 5, 2024
When encoutnering a case like

```rust
//@ run-rustfix
use std::collections::HashMap;

fn main() {
    let vs = vec![0, 0, 1, 1, 3, 4, 5, 6, 3, 3, 3];

    let mut counts = HashMap::new();
    for num in vs {
        let count = counts.entry(num).or_insert(0);
        *count += 1;
    }

    let _ = counts.iter().max_by_key(|(_, v)| v);
```
produce the following suggestion
```
error: lifetime may not live long enough
  --> $DIR/return-value-lifetime-error.rs:13:47
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| v);
   |                                       ------- ^ returning this value requires that `'1` must outlive `'2`
   |                                       |     |
   |                                       |     return type of closure is &'2 &i32
   |                                       has type `&'1 (&i32, &i32)`
   |
help: dereference the return value
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| **v);
   |                                               ++
```

Fix rust-lang#50195.
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 10, 2024
…bank

Provide suggestion to dereference closure tail if appropriate

When encoutnering a case like

```rust
use std::collections::HashMap;

fn main() {
    let vs = vec![0, 0, 1, 1, 3, 4, 5, 6, 3, 3, 3];

    let mut counts = HashMap::new();
    for num in vs {
        let count = counts.entry(num).or_insert(0);
        *count += 1;
    }

    let _ = counts.iter().max_by_key(|(_, v)| v);
```
produce the following suggestion
```
error: lifetime may not live long enough
  --> $DIR/return-value-lifetime-error.rs:13:47
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| v);
   |                                       ------- ^ returning this value requires that `'1` must outlive `'2`
   |                                       |     |
   |                                       |     return type of closure is &'2 &i32
   |                                       has type `&'1 (&i32, &i32)`
   |
help: dereference the return value
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| **v);
   |                                               ++
```

Fix rust-lang#50195.
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 11, 2024
…bank

Provide suggestion to dereference closure tail if appropriate

When encoutnering a case like

```rust
use std::collections::HashMap;

fn main() {
    let vs = vec![0, 0, 1, 1, 3, 4, 5, 6, 3, 3, 3];

    let mut counts = HashMap::new();
    for num in vs {
        let count = counts.entry(num).or_insert(0);
        *count += 1;
    }

    let _ = counts.iter().max_by_key(|(_, v)| v);
```
produce the following suggestion
```
error: lifetime may not live long enough
  --> $DIR/return-value-lifetime-error.rs:13:47
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| v);
   |                                       ------- ^ returning this value requires that `'1` must outlive `'2`
   |                                       |     |
   |                                       |     return type of closure is &'2 &i32
   |                                       has type `&'1 (&i32, &i32)`
   |
help: dereference the return value
   |
LL |     let _ = counts.iter().max_by_key(|(_, v)| **v);
   |                                               ++
```

Fix rust-lang#50195.
@bors bors closed this as completed in 9de6b70 Apr 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. D-confusing Diagnostics: Confusing error or lint that should be reworked. D-verbose Diagnostics: Too much output caused by a single piece of incorrect code. P-medium Medium priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants