Hi Iain,

Thanks for the patch. I didn't see your reply until now (with the BTS
you have to explicitly Cc the bug submitter, see [1]), and in the
meantime I've managed to create a minimal variant of the parsec47
problem. There's a cycle of three modules, one of which does not use
static constructors. I've included the code below.

If you compile this with
gdc -o p47 P47Boot.d Ship.d P47GameManager.d Enemy.d
you get a working program, and
gdc -o p47 Ship.d Enemy.d P47Boot.d P47GameManager.d
gives a broken program.

I don't know if this is correct D code, but it bothers me that the
compiler isn't consistent: either both versions should fail or both
should work. (Consider that it's quite easy to write a build script that
will link the objects in essentially random order, all you have to do is
to use a wildcard to specify your source files.) Given the description
in the manual, I'm guessing it should fail, which would mean that
there's a bug in the cycle detection algorithm.

Regards
Peter De Wachter


[1] http://www.debian.org/doc/developers-reference/pkgs.html#bug-answering

==> P47Boot.d <==
module P47Boot;

import P47GameManager;

import std.stdio;

public int main(char[][] args) {
writefln("Hello world");
return 0;
}

==> P47GameManager.d <==
module P47GameManager;

import Enemy;

public class P47GameManager {
}

==> Enemy.d <==
module Enemy;

import Ship;

public class Enemy{

public static this() {
}

}

==> Ship.d <==
module Ship;

import P47GameManager;

public class Ship {

public static this() {
}

}