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

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m
           Severity|normal                      |blocker

--- Comment #1 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
This currently blocks https://github.com/D-Programming-Language/druntime/pull/990 from working.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> ---
It's not a blocker, as we can work around that, see my new comments in the PR.

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #3 from Martin Nowak <code@dawg.eu> ---
You probably learned that for C++, avoid static constructors because the
initialization order quickly becomes a mess.
The problem here is that both mod2 and mod3 depend on a constructor, but also
have a cyclic dependency. We could somehow (using linker tricks) try to push
the ctors/dtors into mod1.
I'm not sure I understand your idea Steven.

--

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

--- Comment #4 from Steven Schveighoffer <schveiguy@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.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
some help: https://github.com/D-Programming-Language/druntime/pull/1314

--

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

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pro.mathias.lang@gmail.com

--- Comment #6 from Mathias LANG <pro.mathias.lang@gmail.com> ---
This might be related to https://issues.dlang.org/show_bug.cgi?id=20641 which triggers with separate compilation + module ctors in templated code.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--