-
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
cannot infer an appropriate lifetime for pattern should have fix suggestions #50195
Comments
That seems like an unfortunate combination of NLL + the implicit pattern borrow feature. stable reports
while nightly reports some insane borrow error, because Applying the suggestion from the stable compiler or alternatively dereferencing |
Does this even have anything to do with NLL? I think RFC 2005 match ergonomics is the only problematic new feature at play here. |
Nope, not NLL related at all, you're right. Changing the offending line to
emits the same error on stable and nightly. We should simply improve that error and ignore the match ergonomics change. |
Oops, I saw lifetime issues labeld with Thank you for clarification. |
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! |
@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. |
Ping @nikomatsakis @estebank! We're approaching the release of 1.26, do we want to get this regression fixed? |
I'm a bit time constrained at the moment so I can't commit to get this solved before the next release :-/ |
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. |
NLL makes the error better, albeit not ideal:
Still no suggestion with or without NLL. |
Triage, current output:
|
Triage: we now have the nll output. |
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.
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.
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.
…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.
…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.
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.)
The text was updated successfully, but these errors were encountered: