1.25.0-nightly: internal compiler error: unresolved type in dtorck

[bbigras]

nightly-x86_64-pc-windows-msvc (default)
rustc 1.25.0-nightly (3bcda48 2018-02-09)

I'm using tokio_retry and futures_await.

error: internal compiler error: unresolved type in dtorck

error: aborting due to previous error

[Aaron1011]

@bbigras: Can you post the code snippet or repository that you're compiling?

[phrohdoh]

It appears this has regressed since #47322.

[pentlander]

I'm running into the same issue on rustc 1.25.0-nightly (45fba43 2018-02-10)

Any tips on determining which piece of code is causing this?

[Aaron1011]

To anyone experiencing this issue: It would be very helpful to post either a self-contained snippet or link to a repository that causes this crash.

[bbigras]

I'll privately share my horrible code after work if nobody beats me to it. Last night I saw that the problem went away if I removed "nll". It seems I didn't need it on that project.

[bbigras]

Here's a minimal code to reproduce the problem. Note that it builds if we remove the "nll" feature.

nightly-x86_64-pc-windows-msvc (default)
rustc 1.25.0-nightly (3bcda48 2018-02-09)

[dependencies]
futures-await = "0.1"
tokio-core = "0.1"
tokio-retry = "0.1"

#![feature(proc_macro, conservative_impl_trait, generators, nll)]

extern crate futures_await as futures;
extern crate tokio_core;
extern crate tokio_retry;

use futures::prelude::*;
use tokio_core::reactor::Handle;
use tokio_retry::Retry;
use tokio_retry::strategy::ExponentialBackoff;

#[async]
fn something(handle: Handle) -> Result<(), ()> {
    let retry_strategy = ExponentialBackoff::from_millis(10).take(3);

    let retry_future = Retry::spawn(handle, retry_strategy, move || {
        let future_of_1 = futures::future::ok::<(), ()>(());
        future_of_1
    }).map_err(|_| ());

    await!(retry_future)
}

fn main() {}

[FraGag]

I have another minimal repro. This one relies only on the standard library.

struct Inner<I, V> {
    iterator: I,
    item: V,
}

struct Outer<I: Iterator> {
    inner: Inner<I, I::Item>,
}

fn outer<I>(iterator: I) -> Outer<I>
    where I: Iterator,
          I::Item: Default,
{
    Outer {
        inner: Inner {
            iterator: iterator,
            item: Default::default(),
        }
    }
}

fn main() {
    outer(std::iter::once(&1).cloned());
}

It seems the error comes from the usage of an associated type (here, I::Item) in the type of a field combined with the specific type of iterator used here (std::iter::Cloned<std::iter::Once<&i32>>). <std::iter::Cloned as std::iter::Iterator>::Item is a type parameter T that is not directly used in the type of std::iter::Cloned<I>; I suspect that T is the unresolved type that the error message is complaining about.

I found this by isolating the source of the error on one my projects and found that it was caused by the unique iterator combinator from itertools. The struct Unique<I> contains a UniqueBy<I, I::Item, ()> and I was invoking unique on a std::iter::Map<_>. I switched to cloned to show that the bug is not related to closures.

[nikomatsakis]

Question: is everyone here using NLL?

I encountered this problem as well, but only with NLL enabled.

Similarly, @FraGag's example appears to work unless you enable NLL. I see that @bbigras also mentions needing NLL.

[nikomatsakis]

Turns out that this works on my upcoming branch.

[nikomatsakis]

That is, #48411