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

Future compat warning with `.await`ing a `BoxFuture` #62312

Centril opened this issue Jul 2, 2019 · 3 comments


None yet
5 participants
Copy link

commented Jul 2, 2019

The code is the same as in #62284:


use std::future::Future;
use std::pin::Pin;

type BoxFuture = Pin<Box<dyn Future<Output = ()>>>;

async fn foo() -> BoxFuture {
    Box::pin(bar()) as _

async fn bar() {
    let _ = foo().await;

This results in:

warning[E0381]: use of possibly uninitialized variable: `_`
  --> src/
17 |     let _ = foo().await;
   |             ^^^^^^^^^^^ use of possibly uninitialized value
   = warning: this error has been downgraded to a warning for backwards compatibility with previous releases
   = warning: this represents potential undefined behavior in your code and this warning will become a hard error in the future
   = note: for more information, try `rustc --explain E0729`

This comment has been minimized.

Copy link

commented Jul 2, 2019


fn main() {
    let _ = loop {
        break Box::new(()) as Box<dyn Send>;

The MIR we generate is broken, so the borrow checker is correct to complain:

        StorageDead(_2); // _2 is uninit after this.
        _1 = move _2 as std::boxed::Box<dyn std::marker::Send> (Pointer(Unsize));
        drop(_2) -> [return: bb7, unwind: bb6]; // What?

This comment has been minimized.

Copy link

commented Jul 2, 2019

Not an issue on beta.

@Centril Centril added the I-nominated label Jul 2, 2019

@matthewjasper matthewjasper self-assigned this Jul 2, 2019


This comment has been minimized.

Copy link

commented Jul 4, 2019

triage: P-high, removing nomination.

@pnkfelix pnkfelix added P-high and removed I-nominated labels Jul 4, 2019

Centril added a commit to Centril/rust that referenced this issue Jul 5, 2019

Rollup merge of rust-lang#62388 - rust-lang:fix-loop-break-mir-genera…
…tion, r=eddyb

Break out of the correct number of scopes in loops

We were incorrectly breaking out of one too many drop scopes when
generating MIR for loops and breakable blocks, resulting in use after
free and associated borrow checker warnings.

This wasn't noticed because the scope that we're breaking out of twice
is only used for temporaries that are created for adjustments applied to
the loop. Since loops generally propagate coercions to the `break`
expressions, the only case we see this is when the type of the loop is a
smart pointer to a trait object.

Closes rust-lang#62312

@bors bors closed this in #62388 Jul 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.