error: overflow evaluating the requirement `<_ as core::iter::Iterator>::Item`

[mitchmindtree]

src/lib.rs:1:1: 1:1 error: overflow evaluating the requirement `<_ as core::iter::Iterator>::Item` [E0275
src/lib.rs:1 //!                                                                                         
             ^                                                                                           

The error suggests adding a recursion requirement to my crate root

note: consider adding a `#![recursion_limit="128"]` attribute to your crate

It continues to recommend doubling the recursion limit until I've raised it so high that rustc itself overflows it's stack

thread 'rustc' has overflowed its stack                                                                                                                                                            
Could not compile `mindtree_utils`.

Here's a link to the repository that is failing to build in case you would like to give it a go.

The error only appeared in the latest nightly for rustc (I'm fairly sure the crate was building fine before I updated). Here's the version of the nightly I've just downloaded which seems to have caused the failure:

rustc 1.0.0-nightly (123a754cb 2015-03-24) (built 2015-03-25)

[steveklabnik]

Can you show some code that reproduces this?

[mitchmindtree]

Alright, I think I've found the culprit (playpen link).

/// A trait that produces a clone of the previously yielded element along
/// with the current element.
pub trait ZipPrev: Iterator + Sized {
    fn zip_prev(self) -> Items<Self::Item, Self> {
        Items {
            maybe_prev: None,
            iter: self,
        }
    }
}

/// The iterator produced by the zip_prev method.
pub struct Items<A, I> {
    maybe_prev: Option<A>,
    iter: I,
}

impl<I> Iterator for Items<I::Item, I>
    where
        I: Iterator,
        I::Item: Clone,
{
    type Item = (I::Item, Option<I::Item>);
    #[inline]
    fn next(&mut self) -> Option<(I::Item, Option<I::Item>)> {
        let Items { ref mut iter, ref mut maybe_prev } = *self;
        if let Some(item) = iter.next() {
            let old_maybe_prev = maybe_prev.take();
            *maybe_prev = Some(item.clone());
            Some((item, old_maybe_prev))
        } else {
            None
        }
    }
}

impl<I> ZipPrev for I
    where
        I: Iterator,
        I::Item: Clone {}

fn main() {}

Perhaps it's the implementation of Iterator for Items<I::Item, I> where I: Iterator that's causing the recursion? The crate that this came from was compiling a couple days ago (I've only made a couple changes to clean it up a bit before sharing).

[Munksgaard]

We are having similar issues with rust-sessions. Here is the cooked down version:

use std::marker::{PhantomData, PhantomFn};

struct Chan<T> ( PhantomData<T> );

struct Eps;

struct Send<A,R> ( PhantomData<(A, R)> );

trait Dual: PhantomFn<Self> {}

impl Dual for (Eps, Eps) {}

impl <A, T> Dual for (Send<A, T>, Send<A, T>)
    where (T, T): Dual {}

fn request<R, S> (rx: Chan<R>) where (R, S): Dual {
    borrow_request(&rx)
}

fn borrow_request<R, S> (rx: &Chan<R>) where (R, S): Dual {}

That code compiles with rustc 1.0.0-dev (d5408f376 2015-03-19) but not with rustc 1.0.0-dev (b0fd67b3e 2015-03-26)

cc @laumann

[Gerstacker]

Here's another example. This fails with overflow evaluating '_ : core::marker::Sized'. Commenting one line in main and uncommenting its alternative makes the code compile.

https://gist.github.com/Gerstacker/b402c38381604e2ff117

In playpen:
http://is.gd/0bkFkN

[laumann]

What's the status of this?

The example @Munksgaard posts can be "fixed" by adding explicit type annotations to the call to borrow_request(), ie

fn request<R, S> (rx: Chan<R>) where (R, S): Dual {
    borrow_request::<R, S>(&rx)
}

but it's rather unsatisfactory, since whoever calls request() will also be forced to explicitly annotate the function call (and so on).

[Gerstacker]

This annotation workaround fixed mine as well, letting rustc get far enough to expose an embarrassing problem in my code.

[Munksgaard]

It seems like PR #23580 is the cause of this issue. Perhaps @nikomatsakis could comment on whether or not this is intentional?

[Munksgaard]

Specifically, 809a554 compiles my above snippet while 76ead08 doesn't.