On Thursday, 31 May 2018 at 15:15:44 UTC, Steven Schveighoffer
wrote:
On 5/31/18 2:14 AM, Simen Kjærås wrote:
On Wednesday, 30 May 2018 at 20:57:32 UTC, DigitalDesigns
wrote:
Why is this a runtime issue? It is not as if the execution of
static this are non-deterministic. The compiler and linker
must order the calls in some way.
Because of separate compilation, the compiler can't do it.
Because the generic linker doesn't do that sort of thing, the
linker can't do it.
The first part is essentially intractable - e.g. module A's
static this uses a global variable in module B that's set by
module C. Module A may be compiled separately from module C,
so the compiler can't see the dependency.
Yes, this is really the crux of it.
I want to stress that the cycle detection is not really for the
sake of detecting cycles, it's because you need to sort the
modules in the order their static ctors should be called. When
you can't sort them in an order, you have to call them in an
arbitrary order (probably just in the order they were linked).
It is really a shame we have to do this at runtime, but that's
due to the compilation model we are stuck with, and the linker
tools we deal with.
Thinking about this problem for a while I can up with something
that could both reduce the work the runtime had to do and allow
us to remove the error in the OP.
But now I see most of it was suggested in that pull request. [1]
Would the best way to implement this be to extend ModuleInfo and
include a getter that loads the dependencies like
importedModules(), or should the ctor/dtor stuff be moved to a
new tables?
Also we might be able to get the compiler to insert a
cluster_hash that's unique for each compiler run and a
pre-ordered cluster_index. Then use this to speed up sorting in
the runtime.
[1]
https://github.com/dlang/druntime/pull/1602#issuecomment-231527759
