On 6/18/18 3:19 AM, Mr.Bingo wrote:
I have static this scattered throughout. Some are module static this and
some are struct and class.
In a test case I have reduced to a struct that uses a static this and I
get a cycle... even though, of course, the static this does nothing
accept internal things.
It is very annoying to have to hack these cycles. while they can be
bypassed for testing but production requires passing a runtime argument
which is useless for distribution to users.
The cyclic testing is so ignorant that it effectively makes using any
static this with any type of complex importing impossible, even though
no cycles actually exist.
Indeed, the module dependency information is very coarse, so it's very
easy to have "fake" cycles. All we look at is which modules import other
modules.
Note that the cycle detection and ordering is correct, given the limited
information the compiler provides.
Something new has to be done.
I propose that some way be made to disable a static this from being
included in the testing:
@NoCyclicRedundancyCheck static this()
{
}
I'd love to see something like this. Note that the cycle check is not
for redundancy, but for ordering how to call the static ctors. What you
really want to call this is @IndependentCtor or something like that.
This means that this segment of the static ctor does not depend on
anything initialized by other static ctors, and so can be called at any
time.
I'm not sure if attributes will persist at runtime though. Any method is
better than what we have now which essentially prevents all static this
usage because one can't guarantee that the future won't create a cycle
and then the program will break with no easy fix.
It would effectively split the static ctors into 2 functions, one that
can be called independently, and one that has to be sorted. How this is
normally handled is the compiler makes "fake" modules so it can put that
moduleinfo somewhere.
-Steve
