Thread overview
[Issue 8862] New: order of declaration of a function and compile time execution
Oct 21, 2012
Ryuichi OHORI
Oct 21, 2012
Ryuichi OHORI
Oct 21, 2012
Ryuichi OHORI
Oct 22, 2012
Don
October 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8862

           Summary: order of declaration of a function and compile time
                    execution
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: r.97all@gmail.com


--- Comment #0 from Ryuichi OHORI <r.97all@gmail.com> 2012-10-21 06:13:56 PDT ---
I think these two codes below are equivalent, but DMD outputs two lines when compiling the first.

http://dpaste.dzfl.pl/3bcc6b95 http://dpaste.dzfl.pl/167ef2ac

I am not sure this is caused by CTFE, template mixin, something else, or some combination of them.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8862


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2012-10-21 06:37:26 PDT ---
Reduced test case. The the line of initialization of the 'b' variable matters. If it's defined after bar() it compiles, otherwise it doesn't compile:


mixin template Foo() {
    static Spam[1] b = bar(); // Bad.
    static Spam[1] bar() {
        Spam[1] result;
        return result;
    }
    // static Spam[1] b = bar(); // Good.
}
struct Spam {
    mixin Foo!();
}
void main() {}


Initializing 'b' before defining bar() gives the errors:

test.d(3): Error: function test.Spam.Foo!().bar circular dependency. Functions
cannot be interpreted while being compiled
test.d(2):        called from here: bar()
test.d(2):        called from here: bar()
test.d(10): Error: mixin test.Spam.Foo!() error instantiating

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8862



--- Comment #2 from Ryuichi OHORI <r.97all@gmail.com> 2012-10-21 06:47:20 PDT ---
(In reply to comment #1)
> Reduced test case. The line of initialization of the 'b' variable matters. If it's defined after bar() it compiles, otherwise it doesn't compile:

Thanks, but the behavior you reproduced seems different from mine.
In my case, both compiles while the first outputs error-like messages.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8862



--- Comment #3 from bearophile_hugs@eml.cc 2012-10-21 06:53:27 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > Reduced test case. The line of initialization of the 'b' variable matters. If it's defined after bar() it compiles, otherwise it doesn't compile:
> 
> Thanks, but the behavior you reproduced seems different from mine.
> In my case, both compiles while the first outputs error-like messages.

I see. Then try to minimize the code yourself. And then attach/paste it here instead of dpaste, please.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8862



--- Comment #4 from Ryuichi OHORI <r.97all@gmail.com> 2012-10-21 15:11:21 PDT ---
> I see. Then try to minimize the code yourself. And then attach/paste it here instead of dpaste, please.
Actually I was trying to reduce test case for a bug http://d.puremagic.com/issues/show_bug.cgi?id=8865 and came up with another (this) one, so it was difficult for me. Thanks to your code, I managed to minimize see below:

void main()
{
    F!10 x;
}

struct F(int n)
{
    mixin I!n;
}

mixin template I(int n)
{
    int value;
    static F[1] x = get_xs(); // compiles, but outputs: "error.d(14):
called from here: get_xs()"
    static F[1] get_xs()
    {
        return [F(0)];
    }
    //static F[1] x = get_xs(); // compiles, without output.
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 22, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8862


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #5 from Don <clugdbug@yahoo.com.au> 2012-10-22 07:39:56 PDT ---
The difference is simply that bearophile's case is using git head. The "circular dependency" message was missing from previous compiler releases.

This situation is actually a bit strange. It's using sequential semantics, as if it were in a function body, rather than the out-of-order semantics it would have in a struct. This isn't actually a CTFE bug - it should be possible to reproduce this bug without using CTFE.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------