A reduction:


struct MapResult(alias fun) {
    int[] _input;

    @property bool empty() {
        return _input.length == 0;
    }

    void popFront() {
        _input = _input[1 .. $];
    }

    @property auto ref front() {
        return fun(1);
    }
}

auto map(alias fun)(int[] r) {
    return MapResult!(fun)(r);
}

auto foo(int[] r) {
    return map!(x => r)([1]);
}

enum r1 = [1];
auto result = foo(r1);

void main() {
    foreach (t; result) {}
}

Huh, this is really strange. Moving the cartesianProduct line inside main() makes the problem go away. Why?

Hmph. I think this is a compiler bug. Putting the code inside a unittest block makes the problem go away too.

Retitled this bug based on bearophile's reduction, and comparison of the disassembly of buggy version (result assigned to module-global variable) vs. non-buggy version (result assigned to local variable); this looks like a wrong-code bug.

Simplified: 

struct MapResult(alias fun) {
    @property auto ref front() {
        return fun(1);
    }
}

auto map(alias fun)() {
    return MapResult!(fun)();
}

auto foo(int[] r) {
    return map!((int x) => r)();
}

auto result = foo([1]);

void main() {
    result.front();
}

There is wrong-code on accessing or passing module object. It has nothing to do with auto or ranges.

(In reply to Dicebot from comment #0)
> Motivating code snippet:

BTW, this example works since https://github.com/dlang/phobos/pull/2534. The reductions in comment 1 and comment 5 still produce a segfaulting program.

THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/18549

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB