[Issue 14517] Templated static ctor + separate compilation = module cycles

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer <schveiguy at yahoo.com> ---
If you look at PR 990 that Jonathan linked, you will see that it's not so cut
and dry. Essentially ANY separate compiled module that imports another module
that has some template constructors, even if they aren't used in that module,
but used somewhere else, will flag that module as having ctors.

The test I ran showed modules like std.traits having module bits flipped on
because of core.time having static ctors in an instantiated template. That
makes no sense whatsoever -- there's not even an instantiation of MonoTimeImpl
in std.traits.

Let me first say that we need to fix this regardless of how it's done or how
complete the fix is. We absolutely cannot mark some module as having static
ctors because of modules somewhere else in the import chain that have nothing
to do with the given module. If this means banning static ctor/dtor in
templates, so be it (though I think that's a bit difficult to swallow).

And thinking some more about my idea, I don't think it will work. What we
likely need is a way to say that mod2 or mod3 can "upgrade" mod1's bit (at
runtime). Perhaps we can discuss at dconf '15.

--