Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::marker; use std::mem; fn main() { let workers = (0..0).map(|_| result::<u32, ()>()); drop(join_all(workers).poll()); } trait Future { type Item; type Error; fn poll(&mut self) -> Result<Self::Item, Self::Error>; } trait IntoFuture { type Future: Future<Item=Self::Item, Error=Self::Error>; type Item; type Error; fn into_future(self) -> Self::Future; } impl<F: Future> IntoFuture for F { type Future = F; type Item = F::Item; type Error = F::Error; fn into_future(self) -> F { self } } struct FutureResult<T, E> { _inner: marker::PhantomData<(T, E)>, } fn result<T, E>() -> FutureResult<T, E> { loop {} } impl<T, E> Future for FutureResult<T, E> { type Item = T; type Error = E; fn poll(&mut self) -> Result<T, E> { loop {} } } struct JoinAll<I> where I: IntoIterator, I::Item: IntoFuture, { elems: Vec<<I::Item as IntoFuture>::Item>, } fn join_all<I>(_: I) -> JoinAll<I> where I: IntoIterator, I::Item: IntoFuture, { JoinAll { elems: vec![] } } impl<I> Future for JoinAll<I> where I: IntoIterator, I::Item: IntoFuture, { type Item = Vec<<I::Item as IntoFuture>::Item>; type Error = <I::Item as IntoFuture>::Error; fn poll(&mut self) -> Result<Self::Item, Self::Error> { let elems = mem::replace(&mut self.elems, Vec::new()); Ok(elems.into_iter().map(|e| { e }).collect::<Vec<_>>()) } } </ins>

Discussion:
compiles successfully on stable but hits the recursion limit on beta/nightly. This seems like a regression where we hit it too quickly? Is it something we can perhaps fix? The specific error is: cc originally reported as
Inlining for posterity:
Thats... not a recursion limit error Overflow does not cause ambiguity for quite some time.
You mean this used to be the case, but now this is just ambiguous and not due to an overflow?
There's no overflow, only ambiguity and a very outdated error message - overflow last caused ambiguity in the 0.X days.
Then this looks like it's caused by an interaction between a bug(?) in specialization and the new (in beta?) specialization of for . cc Have you seen this fatal error before, when working on code using specialization?
Sure. Trans-time ambiguity is always a bug.
Could we have a mode for logs?
Oh I remember why this is so familiar: on one of my branches I broke a similar specialization by for constraining purposes. But here we can't just look at the history, this could be a bug that was always present in specialization, whether in this sorting logic or elsewhere.
No, I have never seen it.
This is like an annoying problem with the projection cache's handling of nested obligations. Nested projection obligations enter here in this case: Here the normalization result is the result of the nested impl , which is an additional obligation that is a part of "add'l obligations". By itself, this is proper behaviour - the additional obligation is returned, and the RFC 447 rules ensure that it is processed before the output is used in any way. However, the projection cache breaks this - it caches the resolution. Now everybody else that attempts to look up the projection will just get without any additional obligations. This obviously causes all sorts of trouble (here a spurious results in specializations not being discarded ). This appears to work in most cases because during "one-pass evaluation" we tend to process obligations in LIFO order - after an obligation is to the cache, we process its nested obligations before we do anything else (and if we have a cycle, we handle it specifically). And this specific case can be fixed by this little patch that removes the violation of LIFO order: However, I am not sure relying on this "strict LIFO order evaluation" is particularly wise. cc .

I'd r+ that patch, backport it to beta, and separately decide on the underlying design problem.
I feel like I fixed this bug recently UPDATE: Or perhaps a related one. I can't find the branch I was thinking of just now.
Huh. Ah, I dimly recall now. I at one point had a fix that included the obligations in the cache entry, but I wasn't happy about it, and ultimately the problem was fixed by adding a call to , probably the very same one you are talking about now. I think it's ok to rely on LIFO for the time being, though in general I hope we rework a lot of this code to be more general (I... "have thoughts").
Opened PR.