Lifetime suggestion hint interacts weirdly with closures

[ftxqxd]

fn main() {
    let closure = |x: &uint| -> &uint { x };
}

Produces:

<anon>:2:41: 2:42 error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements
<anon>:2     let closure = |x: &uint| -> &uint { x };
                                                 ^
<anon>:1:1: 3:2 note: consider using an explicit lifetime parameter as shown: fn main<'a>()
<anon>:1 fn main() {
<anon>:2     let closure = |x: &uint| -> &uint { x };
<anon>:3 }
error: aborting due to previous error

This is suggesting to put a lifetime on the main function, which certainly is not going to solve the problem here. The real solution is to give closure an explicit type declaration: let closure: <'a>|&'a uint| -> &'a uint = ...;.

Incidentally, is lifetime elision supposed to work on closures, too? Evidently it does not.

[bombless]

fn main() {
    let closure = |x: &u32| -> &u32 { x };
}

Same issue today.
Seems relatively easy to fix, I'll work on it.

[bombless]

rust/src/librustc/middle/infer/error_reporting.rs

Line 820 in 8a60e56

fn give_suggestion(&self, same_regions: &[SameRegions]) {

Given the name give_suggestion here which sounds too general, I think we'd better stop giving advice for this case, but I'm not sure.

In real coding I may try to make a helper function to retrieve the context by reference or even use a macro if I'm in a good mood (which I know might not really be a Rust way). Of course, better to avoid a closure here since lifetimes work better in real context rather than being used as arguments.

[bombless]

I think it's also a valid option that we refactor the error_reporting.rs here to use proper method names, as this "give_suggestion" is not the only method name that looks misleading here.

[bombless]

maybe related: #25005

[Manishearth]

#25005 is probably not related. ast_map's parenting is conceptually broken, but the current rustc code basically relies on this broken code (It uses get_parent to mean "get the parent item or fn")

[steveklabnik]

Triage: no change.

[Mark-Simulacrum]

I don't see any errors after changing uint to u32 today; closing.