ICE on generator type check with a must_use type

[LucioFranco]

ICE is happening on code that awaits a future that has a Output type that is must_use.

Original code:

// src/transport/mod.rs
pub trait Broadcast {
    type Error: std::error::Error;
    type Future: Future<Output = Vec<Result<Response, Self::Error>>> + Unpin;

    fn broadcast(&mut self, req: Request) -> Self::Future;
}

// src/consensus/mod.rs
let request = Request::new(tx, kind);

self.broadcast.broadcast(request).await;
rx.await;

https://github.com/LucioFranco/clique/blob/fbd960b92a2df78c020c94dee565df2d03cf6291/src/consensus/mod.rs#L93

Fix:

// src/consensus/mod.rs
let request = Request::new(tx, kind);

// adding this stops the ICE
let _ = self.broadcast.broadcast(request).await;
rx.await;

ICE MIR Error:

error: internal compiler error: src/librustc_mir/transform/generator.rs:540: Broken MIR: generator contains type std::vec::Vec<std::result::Result<transport::Response, <B as transport::Broadcast>::Error>> in MIR, but typeck only knows about for<'r, 's, 't0, 't1, 't2, 't3> {&'r mut consensus::FastPaxos<'s, C, B>, std::vec::Vec<std::string::String>, futures_util::future::fuse::Fuse<tokio_timer::delay::Delay>, impl core::future::future::Future, (), tokio_sync::oneshot::Sender<std::result::Result<transport::Response, error::Error>>, tokio_sync::oneshot::Receiver<std::result::Result<transport::Response, error::Error>>, transport::proto::RequestKind, transport::Request, <B as transport::Broadcast>::Future}
  --> src/consensus/mod.rs:72:76
   |
72 |       pub async fn propose(&mut self, proposal: Vec<Endpoint>) -> Result<()> {
   |  ____________________________________________________________________________^
73 | |         let mut paxos_delay = Delay::new(Instant::now() + self.get_random_delay()).fuse();
74 | |
75 | |         async {
...  |
97 | |         Ok(())
98 | |     }
   | |_____^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:572:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error


note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.37.0-nightly (02564de47 2019-06-10) running on x86_64-apple-darwin

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `clique`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Rustc version:

rustc 1.37.0-nightly (02564de47 2019-06-10)
binary: rustc
commit-hash: 02564de47b40e953b5144dfd37450c16a84672f1
commit-date: 2019-06-10
host: x86_64-apple-darwin
release: 1.37.0-nightly
LLVM version: 8.0

Full Backtrace:

error: internal compiler error: src/librustc_mir/transform/generator.rs:540: Broken MIR: generator contains type std::vec::Vec<std::result::Result<transport::Response, <B as transport::Broadcast>::Error>> in MIR, but typeck only knows about for<'r, 's, 't0, 't1, 't2, 't3> {&'r mut consensus::FastPaxos<'s, C, B>, std::vec::Vec<std::string::String>, futures_util::future::fuse::Fuse<tokio_timer::delay::Delay>, impl core::future::future::Future, (), tokio_sync::oneshot::Sender<std::result::Result<transport::Response, error::Error>>, tokio_sync::oneshot::Receiver<std::result::Result<transport::Response, error::Error>>, transport::proto::RequestKind, transport::Request, <B as transport::Broadcast>::Future}
  --> src/consensus/mod.rs:72:76
   |
72 |       pub async fn propose(&mut self, proposal: Vec<Endpoint>) -> Result<()> {
   |  ____________________________________________________________________________^
73 | |         let mut paxos_delay = Delay::new(Instant::now() + self.get_random_delay()).fuse();
74 | |
75 | |         async {
...  |
97 | |         Ok(())
98 | |     }
   | |_____^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:572:9
stack backtrace:
   0:        0x10f408cf2 - <unknown>
   1:        0x10f4089e2 - <unknown>
   2:        0x10db6e283 - <unknown>
   3:        0x10f4095c1 - <unknown>
   4:        0x10c7e0bd1 - <unknown>
   5:        0x10c823b5d - <unknown>
   6:        0x10c5a0556 - <unknown>
   7:        0x10c59ef0a - <unknown>
   8:        0x10c59ee9f - <unknown>
   9:        0x10c59eec2 - <unknown>
  10:        0x10c5a0458 - <unknown>
  11:        0x10c5a03ff - <unknown>
  12:        0x10c7db118 - <unknown>
  13:        0x10c51e73c - <unknown>
  14:        0x10c51e373 - <unknown>
  15:        0x10c51f2ef - <unknown>
  16:        0x10db101ff - <unknown>
  17:        0x10d6b2c42 - <unknown>
  18:        0x10d9df455 - <unknown>
  19:        0x10db0eab0 - <unknown>
  20:        0x10d0c36d6 - <unknown>
  21:        0x10d0e426f - <unknown>
  22:        0x10d0c360f - <unknown>
  23:        0x10d0e2924 - <unknown>
  24:        0x10d1ccc8b - <unknown>
  25:        0x10d0c07e2 - <unknown>
  26:        0x10d24b091 - <unknown>
  27:        0x10d0c9620 - <unknown>
  28:        0x10d136964 - <unknown>
  29:        0x10dafdf63 - <unknown>
  30:        0x10b2d7548 - <unknown>
  31:        0x10b323b4d - <unknown>
  32:        0x10b2d7ac2 - <unknown>
  33:        0x10b2c1b81 - <unknown>
  34:        0x10b2d8271 - <unknown>
  35:        0x10b3297b5 - <unknown>
  36:        0x10b2d6f73 - <unknown>
  37:        0x10b2c5152 - <unknown>
  38:        0x10b39af3c - <unknown>
  39:        0x10b15d2e6 - <unknown>
  40:        0x10b1c1867 - <unknown>
  41:        0x10b16efd6 - <unknown>
  42:        0x10b1941d5 - <unknown>
  43:        0x10b1b1eda - <unknown>
  44:        0x10f418d7f - <unknown>
  45:        0x10b147057 - <unknown>
  46:        0x10f3ec8fe - <unknown>
  47:        0x10f417b8e - <unknown>
  48:     0x7fff654d92eb - <unknown>
  49:     0x7fff654dc249 - <unknown>
query stack during panic:
#0 [optimized_mir] processing `consensus::FastPaxos::<'a, C, B>::propose::{{closure}}#0`
end of query stack
error: aborting due to previous error

[Centril]

cc @tmandry @Aaron1011 @matthewjasper

[nikomatsakis]

Could plausibly be related to #61572 -- but that's basically a total guess on my part.

[gilescope]

Going to have a crack at repro and minimising.

[Aaron1011]

I believe this is fixed on the latest nightly

[LucioFranco]

@Aaron1011 You are right, just updated to latest nightly and I can confirm that it's now working. Thanks. Gonna close this.

[gilescope]

minimised repro here: https://github.com/gilescope/clique/tree/repro
(more minimising to come)

[gilescope]

Even better, not needed.

[tmandry]

I think a regression test would still be a good idea.