Lifetime errors on nightly-2019-09-11 but not nightly-2019-09-10

[Bunogi]

The code below will compile without warnings on nightly-2019-09-10, but returns a lifetime error on nightly-2019-09-11 and later.

#[derive(Debug)]
struct A<'a> {
    inner: Vec<&'a str>,
}

struct B {}

impl B {
    async fn something_with_a(&mut self, a: A<'_>) -> Result<(), String> {
        println!("{:?}", a);
        Ok(())
    }
}

async fn can_error(some_string: &str) -> Result<(), String> {
    let a = A { inner: vec![some_string, "foo"] };
    let mut b = B {};
    Ok(b.something_with_a(a).await.map(|_| ())?)
}

fn main() {
    futures::executor::block_on(can_error("foo")).unwrap();
}

cargo +nightly-2019-09-10 build compiles the code without warnings, and cargo +nightly-2019-09-11 build gives the following error:

error[E0597]: `b` does not live long enough
  --> src/main.rs:18:8
   |
18 |     Ok(b.something_with_a(a).await.map(|_| ())?)
   |        ^--------------------
   |        |
   |        borrowed value does not live long enough
   |        a temporary with access to the borrow is created here ...
19 | }
   | -
   | |
   | `b` dropped here while still borrowed
   | ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `impl core::future::future::Future`
   |
   = 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.

error: aborting due to previous error

For more information about this error, try `rustc --explain E0597`.
error: Could not compile `bugreport`.

To learn more, run the command again with --verbose.

Meta

$ rustc +nightly-2019-09-11 --version
rustc 1.39.0-nightly (34e82a7b7 2019-09-10)

[nikomatsakis]

This too is fallout from #64292, similar to #64477. I've written up a long report on the change that caused this and its motivations. The report also discussed whether we should consider revering that change, and what that would mean.

Let's keep discussion about the pro/con of the decision confined to #64477 though.

[PvdBerg1998]

I hit the same issue with something like this:

async fn something<B: Borrow<Foo>>(b: B) {
   other(b.borrow()).await;
}

[nikomatsakis]

The original example, at least, is fixed by #64584

[nikomatsakis]

Also this is likely a duplicate of #64391 at this point