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

Eyal <eyal@weka.io> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal

--

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

Ali Cehreli <acehreli@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry
                 CC|                            |acehreli@yahoo.com

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
The same error:

test.d(10): Error: couldn't find field i of type int in OpApply()
test.d(3):        called from here: dlg(1)
test.d(9):        called from here: OpApply().opApply(delegate int(int _) => 0)
test.d(14):        called from here: Foo(0).this(1)

happens when `enum` is replaced with `auto` so it is not specific to CTFE.

--

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

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g@gmail.com

--- Comment #2 from ag0aep6g@gmail.com ---
(In reply to Walter Bright from comment #1)
> The same error:
[...]
> happens when `enum` is replaced with `auto` so it is not specific to CTFE.

I think you're mistaken. If you leave x at the module level, it's still initialized statically, i.e. CTFE is involved. The error goes away when x is a function-local variable.

--

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

--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to ag0aep6g from comment #2)
> I think you're mistaken.

You're right. It is a CTFE problem.

--

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

--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> ---
The following simpler code reproduces the problem:

------------------------
struct OpApply {
    void opApply(void delegate() dlg) {
        dlg();
    }
}
struct Foo {
    int i;

    int abc() {
    auto o = OpApply();
    void dg() { i = 0; } // couldn't find field i of type int in OpApply()
    o.opApply(&dg);
    return 0;
    }
}

void bar() {
    enum x = Foo().abc();
}
---------------------------

This code fails in a similar manner, and also works outside of CTFE (replace enum with auto and it compiles):
---------------------------
void opApply(void delegate() dlg) { dlg(); }

struct Foo {
    int i;

    int abc() {
        void dg() { i = 0; } // value of 'this' is not known at compile time
        opApply(&dg);
        return 0;
    }
}

void bar() {
    enum x = Foo().abc();
}
-------------------------

This stuff is pretty deep in the bowels of CTFE, which I don't really understand :-(

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |CTFE

--

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

uplink.coder@googlemail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uplink.coder@googlemail.com

--- Comment #5 from uplink.coder@googlemail.com ---
We generally have no support for closures at ctfe.

--

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

--- Comment #6 from uplink.coder@googlemail.com ---
I figured out what is happing.

The delegate support code in the ctfe engine takes the parents scope to try and extract a thisPtr.

in the case of walters example

struct Foo {
    int i;

    int abc() {
        void dg() { i = 0; } // value of 'this' is not known at compile time
                             // dg's direct parent is the function abc, which
                             // does not have a this (because it's a function)
        opApply(&dg);
        return 0;
    }
}

void bar() {
    enum x = Foo().abc();
}

I am working on a solution.
It should work in a couple of days.

--

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

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
Don Clugston writes about this problem:

I bet the problem is around dinterpret.d line 4966.

---
        else if (ecall.op == TOKdelegate)
        {
            // Calling a delegate
            fd = (cast(DelegateExp)ecall).func;
            pthis = (cast(DelegateExp)ecall).e1;

            // Special handling for: &nestedfunc -->
DelegateExp(VarExp(nestedfunc), nestedfunc)
            if (pthis.op == TOKvar && (cast(VarExp)pthis).var == fd)
                pthis = null; // context is not necessary for CTFE
---

"Context is not necessary for CTFE".
I doubt very much that that is true.

--