https://issues.dlang.org/show_bug.cgi?id=11826

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--

https://issues.dlang.org/show_bug.cgi?id=11826

--- Comment #1 from hsteoh@quickfur.ath.cx ---
This appears to be a bug in std.algorithm.map: here's a minimal test case reduced from the implementation of cartesianProduct:

------
import std.stdio: writeln;
import std.algorithm;

auto f(R1)(R1 range1)
{
    return [1].map!(a => range1);
}

auto r = f([1, 2, 3]);

void main() {
    r.writeln;
}
------

Moving r inside main() fixes the problem.

--

https://issues.dlang.org/show_bug.cgi?id=11826

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|Windows                     |All

--

https://issues.dlang.org/show_bug.cgi?id=11826

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |wrong-code

--

https://issues.dlang.org/show_bug.cgi?id=11826

--- Comment #2 from hsteoh@quickfur.ath.cx ---
Managed to reduce it to this near-minimal segfaulting test case:

------
struct MapResult(alias fun, Range)
{
    @property front()
    {
        return fun(0);
    }
}

auto f(R1)(R1 range1)
{
    return MapResult!(a => range1, int[])();
}

auto r = f([2]);

void main() {
    r.front;
}
------

Seems to be a codegen bug; moving the declaration of r inside main() fixes the problem. Disassembly from inside gdb shows a null pointer dereference inside the lambda. Not sure exactly what pointer that is yet, but I suspect it's trying to access the stack frame of f() to get at the parameter 'range1', which has gone out of scope.

--

https://issues.dlang.org/show_bug.cgi?id=11826

--- Comment #3 from hsteoh@quickfur.ath.cx ---
An even more minimal test case:
------
struct S(alias fun)
{
    auto g() { return fun(0); }
}
auto f(int[] arr)
{
    return S!(a => arr)();
}
auto r = f([2]);
void main() {
    r.g();
}
------

--

https://issues.dlang.org/show_bug.cgi?id=11826

--- Comment #4 from hsteoh@quickfur.ath.cx ---
Actually, the parameter to f() doesn't have to be an array:
------
struct S(alias fun)
{
    auto g() { return fun(0); }
}
auto f(int arr)
{
    return S!(a => arr)();
}
auto r = f(2);
void main() {
    r.g();
}
------

This seems to prove conclusively that the problem is caused by the lambda trying to access the out-of-scope stack frame of f().

--

https://issues.dlang.org/show_bug.cgi?id=11826

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |CTFE, diagnostic
          Component|Phobos                      |DMD

--- Comment #5 from hsteoh@quickfur.ath.cx ---
As pointed out by Timon Gehr on the forum, this bug seems to be a failure to
detect an unsupported feature in CTFE. Moving r=f(2) line into main() and
changing it from auto to enum (to force CTFE) triggers the same problem.

--

https://issues.dlang.org/show_bug.cgi?id=11826

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|An Access Violation in      |[ctfe] CTFE fails to issue
                   |Phobos with                 |diagnostic for unsupported
                   |cartesianProduct at         |feature of closures
                   |compile-time                |

--

https://issues.dlang.org/show_bug.cgi?id=11826

Seb <greensunny12@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |greensunny12@gmail.com
         Resolution|---                         |FIXED

--- Comment #6 from Seb <greensunny12@gmail.com> ---


2.062   to 2.066.0: Failure with output: --- killed by signal 11
Since      2.067.1: Success with output: [Tuple!(int, int)(1, 10), Tuple!(int,
int)(1, 20), Tuple!(int, int)(1, 30), Tuple!(int, int)(2, 10), Tuple!(int,
int)(2, 20), Tuple!(int, int)(2, 30), Tuple!(int, int)(3, 10), Tuple!(int,
int)(3, 20), Tuple!(int, int)(3, 30)]


https://run.dlang.io/is/Bb5RGA

--