async/await assertion failed: unbounded recursion

[Ekleog]

(edit: much simpler reproducer at second post)

(see edit history for the initial issue text)

Potential duplicate of #49537 and #51624

cc #50547

[Ekleog]

(edit: updated to nightly from 2018-08-14, as the error message changed)

Another simpler reproducer:

#![feature(async_await, await_macro, futures_api)]

use futures::prelude::*;

async fn __receive<WantFn, Fut>(want: WantFn) -> ()
where
    Fut: Future<Output = ()>,
    WantFn: Fn(&Box<Send + 'static>) -> Fut,
{
    await!(futures::future::lazy(|_| ()));
}

pub fn basic_spawn_receive() {
    async { await!(__receive(|_| async { () })) };
}

Cargo.toml:

cargo-features = ["edition"]

[package]
name = "erlust"
edition = "2018"
version = "0.1.0"

[dependencies.futures-preview]
git = "https://github.com/rust-lang-nursery/futures-rs"
rev = "c02ec75a155485ff4b50f21205b6a462851b08e1"

Backtrace:

error[E0275]: overflow evaluating the requirement `[closure@erlust/src/lib.rs:10:34: 10:40]: std::marker::Freeze`
  |
  = help: consider adding a `#![recursion_limit="128"]` attribute to your crate
  = note: required because of the requirements on the impl of `std::marker::Freeze` for `[closure@erlust/src/lib.rs:10:34: 10:40]`
[…]
  = note: required because of the requirements on the impl of `std::marker::Freeze` for `[closure@erlust/src/lib.rs:10:34: 10:40]`
  = note: required because it appears within the type `std::option::Option<[closure@erlust/src/lib.rs:10:34: 10:40]>`
  = note: required because it appears within the type `futures_util::future::lazy::Lazy<[closure@erlust/src/lib.rs:10:34: 10:40]>`
  = note: required because it appears within the type `{futures_util::future::lazy::Lazy<[closure@erlust/src/lib.rs:10:34: 10:40]>, ()}`
  = note: required because it appears within the type `[static generator@erlust/src/lib.rs:9:1: 11:2 {futures_util::future::lazy::Lazy<[closure@erlust/src/lib.rs:10:34: 10:40]>, ()}]`
  = note: required because it appears within the type `std::future::GenFuture<[static generator@erlust/src/lib.rs:9:1: 11:2 {futures_util::future::lazy::Lazy<[closure@erlust/src/lib.rs:10:34: 10:40]>, ()}]>`
  = note: required because it appears within the type `impl core::future::future::Future`
  = note: required because it appears within the type `impl core::future::future::Future`
  = note: required because it appears within the type `for<'r> {impl core::future::future::Future, ()}`
  = note: required because it appears within the type `[static generator@erlust/src/lib.rs:14:11: 14:50 for<'r> {impl core::future::future::Future, ()}]`
  = note: required because it appears within the type `std::future::GenFuture<[static generator@erlust/src/lib.rs:14:11: 14:50 for<'r> {impl core::future::future::Future, ()}]>`
  = note: required because it appears within the type `impl core::future::future::Future`

error: aborting due to previous error

The backtrace looks quite different though, so I guess a fix for this one should also be checked to fix the first example.

[Ekleog]

Latest nightly appears to have fixed the ICE, however it's still making unbounded recursion :)

[nikomatsakis]

Async-await traige: Marking as blocking pending investigation to understand what is happening.

[davidtwco]

Alright, so here's what I've worked out so far:

I was able to reproduce the ICE from the original code snippet using the compiler version and library versions from when the issue was reported (nightly-2018-08-05 was the closest version I could find and I had to use patch to make Cargo download versions of libraries that worked). I was then able to confirm that the reproduction supplied in the next comment also triggered the ICE. I was then able to get rid of the external dependencies (mostly by copying in parts of that version of futures) and still get the ICE - here's that test case.

After that, I upgraded to nightly-2018-08-14 as mentioned in the next comment and confirmed that the ICE had been fixed and the unbounded recursion was happening with that same test case. Then, I took that test case that was confirmed to have the problem and tried to run it on the latest nightly - I had to make some minor adjustments as the pin module had changed since August, but I couldn't get the recursion error to happen. I'm inclined to say that this has been fixed at some point - here's what I ended up running.

[davidtwco]

I've submitted #60243 with a regression test for this issue.

@Ekleog if you are able to reproduce this failure on a more recent nightly then feel free to re-open or file a new issue.