Skip to content

Confusing lifetime inference with a closure #36867

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

Closed
hardenedapple opened this issue Sep 30, 2016 · 3 comments
Closed

Confusing lifetime inference with a closure #36867

hardenedapple opened this issue Sep 30, 2016 · 3 comments
Labels
A-closures Area: Closures (`|…| { … }`) A-inference Area: Type inference A-lifetimes Area: Lifetimes / regions C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@hardenedapple
Copy link

The code below compiles and runs as I expect, but when the type annotation is uncommented rustc gives lifetime errors.

I've seen a few similar but not quite the same issues, but I don't think this particular one is already logged (apologies if that's not the case).

use std::vec::Vec;
fn main() {
    let nodes = (0..3).collect::<Vec<u32>>();
    let references = nodes.iter().map(
        |x
        // : &u32 // If this line is uncommented I get lifetime problems
        | x).collect::<Vec<_>>();
    println!("references: {:?}", references);
}

Using the trivial function below instead of a closure compiles without errors.

fn return_reference(x: &u32) -> &u32 {
    x
}
@mbrubeck
Copy link
Contributor

Slightly similar to #24421.

@steveklabnik steveklabnik added A-lifetimes Area: Lifetimes / regions A-closures Area: Closures (`|…| { … }`) labels Oct 7, 2016
@cyplo
Copy link
Contributor

cyplo commented May 6, 2017

It still gives lifetime errors on rustc 1.18.0-nightly (28a7429 2017-04-13):

error[E0495]: cannot infer an appropriate lifetime due to conflicting requirements
 --> test.rs:7:11
  |
7 |         | x).collect::<Vec<_>>();
  |           ^
  |
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the body at 7:10...
 --> test.rs:7:11
  |
7 |         | x).collect::<Vec<_>>();
  |           ^
note: ...so that expression is assignable (expected &u32, found &u32)
 --> test.rs:7:11
  |
7 |         | x).collect::<Vec<_>>();
  |           ^
note: but, the lifetime must be valid for the method call at 4:21...
 --> test.rs:4:22
  |
4 |       let references = nodes.iter().map(
  |  ______________________^ starting here...
5 | |         |x
6 | |         : &u32 // If this line is uncommented I get lifetime problems
7 | |         | x).collect::<Vec<_>>();
  | |________________________________^ ...ending here
note: ...so type `fn(std::iter::Map<std::slice::Iter<'_, u32>, [[email protected]:5:9: 7:12]>) -> std::vec::Vec<&u32> {<std::iter::Map<std::slice::Iter<'_, u32>, [[email protected]:5:9: 7:12]> as std::iter::Iterator>::collect::<std::vec::Vec<&u32>>}` of expression is valid during the expression
 --> test.rs:4:22
  |
4 |       let references = nodes.iter().map(
  |  ______________________^ starting here...
5 | |         |x
6 | |         : &u32 // If this line is uncommented I get lifetime problems
7 | |         | x).collect::<Vec<_>>();
  | |________________________________^ ...ending here

error: aborting due to previous error

@Mark-Simulacrum Mark-Simulacrum added the A-inference Area: Type inference label Jun 22, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 26, 2017
@memoryruins
Copy link
Contributor

With and without a type annotation, the example currently builds and runs on stable rustc 1.30.0 (da5f414c2 2018-10-24) as well as on nightly (2015/2018).
Checking compiler explorer, the example has built successfully since 1.23.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-closures Area: Closures (`|…| { … }`) A-inference Area: Type inference A-lifetimes Area: Lifetimes / regions C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

6 participants