Bug 9822 – Using module variable of templated type parametrized by lambda

Motivating code snippet: ----- module test; import std.algorithm, std.traits, std.stdio; enum r1 = [1, 2, 3]; auto product = cartesianProduct(r1, r1); void main() { writeln(product); } ----- Segmentation fault ----- What is expected: either working code, or compile-time error.

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