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

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)

Can you show some code that reproduces this?

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).

@laumann

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

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

@Munksgaard

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).

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

@nikomatsakis

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

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

23707

This no longer ICEs.

@bluss

Triage: @bluss example still overflows.

Not sure if this is relevant, but a popular lib tokio seems triggers this error when used with Rc in a certain way.

extern crate tokio_core;
extern crate tokio_io;

use std::{borrow::Borrow, rc::Rc};
use tokio_core::net::TcpStream;
use tokio_io::io::read_exact;

fn read_one(conn: Rc<TcpStream>) {
    read_exact(conn.borrow(), [0u8]);
}

Stackoverflow question

The workaround is to use

read_exact(&*conn,[0u8]);

But for new users this will just get them confused.

Here's another one that overflows. Is it supposed to? (and if not, is there a workaround?)

trait X {
    type Item;
}

trait Y {
    type Item: X;
}

impl<T: Y> X for T {
    type Item = <Self::Item as X>::Item;
}

// error[E0275]: overflow evaluating the requirement `<T as X>::Item`
//  --> src/main.rs:9:12
//   |
// 9 | impl<T: Y> X for T {
//   |            ^       ^

Another somehow simple example:

use std::borrow::Cow;
enum Test <'a> {
    Int(u8),
    Array(Cow<'a, [Test<'a>]>),
}

It seems like this is happening whenever an associated type is referenced while it's still evaluating the impl it's defined in, here is a small example that seems like it should be fine:

trait TraitWithAssociatedType {
    type AssociatedType;
}
trait AnyTrait { }
struct StructWithImpl;
struct AnyStruct;

impl TraitWithAssociatedType for StructWithImpl where Self::AssociatedType: AnyTrait {
    type AssociatedType = AnyStruct;
}

Intuitively it seems like the overflow might be comming from infinite recursion when it tries to check the impl TraitWithAssociatedType, which requires it to evaluate Self::AssociatedType to see whether it should apply to StructWithImpl, but that means it tries to first evaluate the whole impl TraitWithAssociatedType to get AssociatedType, even if it could just use the definition type AssociatedType = AnyStruct. (Might be wrong about this, I'm not a compiler writer, that's just what seems to make sense to me.)

In this case replacing Self::AssociatedType with AnyStruct fixes the problem, but that means writing the type out in full, and there might be some places where that is either not possible or requires a lot of duplication.

Rollup merge of rust-lang#132312 - jieyouxu:delete-crashes-23707, r=m…

Unrolled build for rust-lang#132312

Navigation Menu

Repository navigation

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

14 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

steveklabnik commented on Mar 26, 2015

mitchmindtree commented on Mar 26, 2015

Munksgaard commented on Mar 26, 2015

Gerstacker commented on Apr 3, 2015

laumann commented on Apr 9, 2015

Gerstacker commented on Apr 9, 2015

Munksgaard commented on Apr 12, 2015

Munksgaard commented on Apr 12, 2015

steveklabnik commented on Nov 6, 2015

14 remaining items

brson commented on Jun 27, 2016

earthengine commented on May 7, 2018

aldanor commented on Jan 1, 2019

marmeladema commented on Nov 21, 2019

LukeMiles49 commented on Jul 11, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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