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 .awaiting a BoxFuture #62312

Centril opened this issue Jul 2, 2019 · 3 comments

Future compat warning with .awaiting a BoxFuture #62312

Centril opened this issue Jul 2, 2019 · 3 comments


Copy link

@Centril Centril 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`
Copy link

@matthewjasper matthewjasper 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?


Copy link

@matthewjasper matthewjasper commented Jul 2, 2019

Not an issue on beta.


@matthewjasper matthewjasper self-assigned this Jul 2, 2019
Copy link

@pnkfelix pnkfelix commented Jul 4, 2019

triage: P-high, removing nomination.


Centril added a commit to Centril/rust that referenced this issue Jul 5, 2019
…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
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants