nightly-x86_64-pc-windows-msvc (default)
rustc 1.25.0-nightly (3bcda48a3 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
@bbigras: Can you post the code snippet or repository that you're compiling?
It appears this has regressed since https://github.com/rust-lang/rust/pull/47322.
I'm running into the same issue on rustc 1.25.0-nightly (45fba43b3 2018-02-10)
Any tips on determining which piece of code is causing this?
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.
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.
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 (3bcda48a3 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() {}
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.
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.
Turns out that this works on my upcoming branch.
Most helpful comment
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.