cannot infer an appropriate lifetime for pattern should have fix suggestions

[hellow554]

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]

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.

[LukasKalbertodt]

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]

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.

[hellow554]

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

Thank you for clarification.

[nikomatsakis]

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]

@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]

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

[estebank]

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

[nikomatsakis]

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.