Segfault when calling Take<Take<Repeat<T>>>::count for certain T

[autumnontape]

The following function segfaults when compiled at opt-level 2 or 3:

fn segfaults() -> usize {
    core::iter::repeat(()).take(1).take(1).count()
}

The Compiler Explorer output is here. You can see it produces this very strange line of assembly at the beginning of the function:

mov     rdx, QWORD PTR ds:0

GDB confirms that this is where the segfault occurs.

I doubt it's about the iter, I think it's about trying to work with a zero sized type (()). Support for zero-sized types is very rudimentary at the moment, so expect all sorts of weird behavior when doing things on ZSTs 😢

Oh no, that reproduces even with integer types

fn segfaults() -> usize {
    core::iter::repeat(42i32).take(1).take(1).count()
}

example::segfaults:
        mov     rdx, QWORD PTR ds:0
        mov     eax, 1
        mov     rcx, rdx

[autumnontape]

On the other hand, it produces the expected (non-segfaulting) code when I give it [0u128; 5000] instead of () or 42i32.

[antoyo]

That seems fixed, now. Maybe thanks to #104.
Can you confirm it is indeed fixed?

[autumnontape]

Yes, the snippet I included in the issue description compiles with the latest commit, and the real-world project it was minimized from compiles and passes tests now.