There are quite a few projects that broke b/c we fixed the cyclic module checker.
We should try to relax the conservative import analysis.
It seems that any static ctor/dtor only using symbols from the local module cannot produce cycles just b/c of that and thus be marked as standalone.
Also cycles coming from imports in unittest blocks could possibly be ignored.
[¹]: https://github.com/dlang/druntime/pull/1602
[²]: https://github.com/dlang/druntime/pull/1602#issuecomment-231527759
Comment #1 by dfj1esp02 — 2016-11-09T10:30:31Z
What about indirect dependencies? Functions in the module can import other modules, they will misbehave if not initialized.
Comment #2 by schveiguy — 2016-11-09T16:44:54Z
I think Martin meant *data* symbols, not functions. Obviously function symbols in local module can depend on external items. Of course, the compiler could extend the check to the local function as well if possible.
I'd go further and say that depending on external compile-time constants can also be allowed (e.g. enums).
Comment #3 by uplink.coder — 2016-11-24T02:11:24Z
In this particular case the initialization order is not important, because only static properties of the imported classes are used.
I will have a look later.
Comment #4 by uplink.coder — 2016-11-24T02:13:13Z
wrong bug Oo.
was supposed to go to
Issue 16491
Comment #5 by code — 2017-02-18T18:16:23Z
And obviously nested functions within the ctor.
This would turn all ctors in Higgs to standalone ctors. Data initialization is the biggest use-case for ctors, so this would likely solve many cyclic module issues.
Comment #6 by code — 2017-02-18T18:42:10Z
Should be fairly easy with the new 2-step lookup process (SearchLocalsOnly, SearchImportsOnly), just instrument all symbol searches in expression.d to tag the current scope's func as usesImports, when only the SearchImportsOnly lookup returns a symbol.
Furthermore CallExp's using such functions also need to tag their scope's function to make it work transitively.
Comment #7 by robert.schadek — 2024-12-07T13:36:59Z