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

"does not live long enough" when returning Option<impl trait> #55535

Open
Riateche opened this issue Oct 31, 2018 · 2 comments
Open

"does not live long enough" when returning Option<impl trait> #55535

Riateche opened this issue Oct 31, 2018 · 2 comments

Comments

@Riateche
Copy link

@Riateche Riateche commented Oct 31, 2018

This doesn't compile:

use std::cell::RefCell;

struct B;
struct A {
    b: B,
}

impl A {
    fn b(&self) -> Option<impl Iterator<Item = &B>> {
        Some(::std::iter::once(&self.b))
    }
}

fn func(a: RefCell<A>) {
    let lock = a.borrow_mut();
    if let Some(_b) = lock.b() {}
}

However, it compiles when impl trait is replaced with the concrete type:

fn b(&self) -> Option<::std::iter::Once<&B>> {

It also compiles with impl trait if Option is removed:

impl A {
    fn b(&self) -> impl Iterator<Item = &B> {
        ::std::iter::once(&self.b)
    }
}

fn func(a: RefCell<A>) {
    let lock = a.borrow_mut();
    let _b = lock.b();
}
@pnkfelix
Copy link
Member

@pnkfelix pnkfelix commented Nov 2, 2018

cc #46413 because I think this may be a result of our temporary lifetime rules (and perhaps some interaction between them and other features like variance)

here is the message we currently emit from the 2018 edition for the given code:

error[E0597]: `lock` does not live long enough
  --> src/lib.rs:16:23
   |
16 |     if let Some(_b) = lock.b() {}
   |                       ^^^^----
   |                       |
   |                       borrowed value does not live long enough
   |                       a temporary with access to the borrow is created here ...
17 | }
   | -
   | |
   | `lock` dropped here while still borrowed
   | ... and the borrow might be used here, when that temporary is dropped and \
         runs the destructor for type `std::option::Option<impl std::iter::Iterator>`
   |
   = note: The temporary is part of an expression at the end of a block. \
     Consider adding semicolon after the expression so its temporaries are \
     dropped sooner, before the local variables declared by the block are dropped.

Following the advice provided (by adding a semicolon after the if let expression) does allow the code to compile, for better or for worse.

@matthew-mcallister
Copy link
Contributor

@matthew-mcallister matthew-mcallister commented Jun 28, 2020

I seem to have found another similar case where this happens. If an impl Iterator borrowing a temporary is used in the final expression of a block, it causes the same compiler error. Switching to a return statement solves the error.

struct Array {
    inner: [u32; 3],
}

impl Array {
    fn iter(&self) -> impl Iterator<Item = &u32> {
        self.inner.iter()
    }

    fn compare(&self) -> bool {
        let foo2 = Array { inner: [1, 2, 3u32] };
        self.iter().zip(foo2.iter()).all(|(&x, &y)| x > y)
        // Switching to a return statement fixes it:
        //return self.iter().zip(foo2.iter()).all(|(&x, &y)| x > y);
    }
}

The error message actually does show how to fix the problem, though it's still fairly silly.

Output:

error[E0597]: `foo2` does not live long enough
  --> src/lib.rs:12:25
   |
12 |         self.iter().zip(foo2.iter()).all(|(&x, &y)| x > y)
   |         ----------------^^^^--------
   |         |               |
   |         |               borrowed value does not live long enough
   |         a temporary with access to the borrow is created here ...
...
15 |     }
   |     -
   |     |
   |     `foo2` dropped here while still borrowed
   |     ... and the borrow might be used here, when that temporary is dropped and runs the
destructor for type `std::iter::Zip<impl std::iter::Iterator, impl std::iter::Iterator>`
   |
   = note: The temporary is part of an expression at the end of a block. Consider forcing this
temporary to be dropped sooner, before the block's local variables are dropped. For example,
you could save the expression's value in a new local variable `x` and then make `x` be the
expression at the end of the block.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants