rayon hangs

[compiler-errors]

pub trait ParallelIterator {
    type Item;
}

macro_rules! multizip_impls {
    ($(
        $Tuple:ident {
            $(($idx:tt) -> $T:ident)+
        }
    )+) => {
        $(
            impl<$( $T, )+> ParallelIterator for ($( $T, )+)
            where
                $(
                    $T: ParallelIterator,
                    $T::Item: ParallelIterator,
                )+
            {
                type Item = ();
            }
        )*
    }
}

multizip_impls! {
    Tuple1 {
        (0) -> A
    }
    Tuple2 {
        (0) -> A
        (1) -> B
    }
    Tuple3 {
        (0) -> A
        (1) -> B
        (2) -> C
    }
    Tuple4 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
    }
    Tuple5 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
    }
    Tuple6 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
    }
    Tuple7 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
    }
    Tuple8 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
    }
    Tuple9 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
    }
    Tuple10 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
        (9) -> J
    }
    Tuple11 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
        (9) -> J
        (10) -> K
    }
    Tuple12 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
        (9) -> J
        (10) -> K
        (11) -> L
    }
}

fn main() {}

[compiler-errors]

Some sort of combinatorial blow up when we are trying to prove the WC on each impl are well-formed -- I think we might be trying prove things like A::Item: ParallelIterator via B::Item: ParallelIterator leading to way too many alias-relate goals being emitted even though they're effectively useless.

[lcnr]

this very much makes sense to me🤔 can chat about it tomorrow, I guess we may want to assume (for completeness, not soundness) that all self-types of ParamEnv are normalized, and then do a structural lookup when considering param env candidates, similar to impls

edit: or well, unsure how this interacts with normalizing in an unnormalized env xx

also, how to avoid this hang when first normalizing the env

[lcnr]

rayon has a blanket impl of ParallelIterator

pub trait IntoParallelIterator {
    type Item;
}

trait ParallelIterator {}
impl<T: ParallelIterator> IntoParallelIterator for T {
    type Item = T;
}

macro_rules! multizip_impls {
    ($(
        $Tuple:ident {
            $(($idx:tt) -> $T:ident)+
        }
    )+) => {
        $(
            impl<$( $T, )+> IntoParallelIterator for ($( $T, )+)
            where
                $(
                    $T: IntoParallelIterator,
                    $T::Item: ParallelIterator,
                )+
            {
                type Item = ();
            }
        )*
    }
}

multizip_impls! {
    Tuple1 {
        (0) -> A
    }
    Tuple2 {
        (0) -> A
        (1) -> B
    }
    Tuple3 {
        (0) -> A
        (1) -> B
        (2) -> C
    }
    Tuple4 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
    }
    Tuple5 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
    }
    Tuple6 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
    }
    Tuple7 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
    }
    Tuple8 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
    }
    Tuple9 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
    }
    Tuple10 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
        (9) -> J
    }
    Tuple11 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
        (9) -> J
        (10) -> K
    }
    Tuple12 {
        (0) -> A
        (1) -> B
        (2) -> C
        (3) -> D
        (4) -> E
        (5) -> F
        (6) -> G
        (7) -> H
        (8) -> I
        (9) -> J
        (10) -> K
        (11) -> L
    }
}

fn main() {}

[lcnr]

rayon has a blanket impl of ParallelIterator

This minimization is still insufficient (now). With rust-lang/rust#124852 this test compiles but rayon hangs

[lcnr]

The hang occurs in fn check_type_bounds: minimization without relying on this:

trait ParallelIterator: Sized {
    type Item;
}
trait IntoParallelIterator {
    type Iter: ParallelIterator<Item = Self::Item>;
    type Item;
}
impl<T: ParallelIterator> IntoParallelIterator for T {
    type Iter = T;
    type Item = T::Item;
}

macro_rules! multizip_impls {
    ($($T:ident),+) => {
       fn foo<$( $T, )+>() where
        $(
            $T: IntoParallelIterator,
            $T::Iter: ParallelIterator,
        )+
            ($( $T, )+): IntoParallelIterator<Item = ($( $T::Item, )+)>,
        {}
    }
}

multizip_impls! { A, B, C, D, E, F, G, H, I, J, K, L }

The added ($( $T, )+): IntoParallelIterator<Item = ($( $T::Item, )+)> where-clause disables the alias-relate fast path optimization

[lcnr]

To fix this we can either strengthen rust-lang/rust#124852 which feels fairly hacky.

I'd like to instead look into making fn rebase_provisional_cache_entries far more powerful so that we don't need rust-lang/rust#124852 at all.