Using `.iter()` with itertools returns empty cartesian product

[mlund]

This code runs as expected, but is slow:

use itertools::iproduct;
const X: [u8; 2] = [1,2];
const Y: [u8; 3] = [11,12,13];
for (x, y) in iproduct!(X, Y) {
    println!("{} {}", x, y);
}

whereas this (significantly faster) version never enters the loop as if the cartesian product is empty:

for (x, y) in iproduct!(X.iter(), Y.iter()) {
    println!("{} {}", x, y);
}

This is tested with the rust-mos docker image (Oct. 9, 2022) and itertools 0.10.5. The .iter() variant used to work (summer 2022), but I still get the unexpected behavior when rolling back the itertools version. The issue persists for both and c64, mega65 and sim targets.

Update: The issue appear when using optimization level s or z. For level 2 and 3 the .iter() version works!

[mlund]

Adding panic_immediate_abort to .cargo/Config.toml fixes the issue also for optimization levels s and z:

[unstable]
build-std = ["core", "alloc"]
build-std-features = ["panic_immediate_abort"]

Thanks to @mrk-its!

[sagacity]

Nice! I haven't been able to test this yet since the computer containing the toolchain got replaced, and it's not zero effort to rebuild the entire thing. But I'll try again once I have some time.

[mlund]

Yep, it requires some patience to build the toolchain :-) I just use the Docker images on Dockerhub (mrkits/rust-mos for x86 and mikaellund/rust-mos for arm)

[sagacity]

Did a quick test and I can confirm it's working now! I did see some strings in the final release binary related to gdb, oddly enough, but I didn't have the time to dive into that.

[mrk-its]

It looks it works with last rust-mos build (even without panic_immediate_abort hack), closing.