https://issues.dlang.org/show_bug.cgi?id=23974
Issue ID: 23974
Summary: A ModuleInfo in a separate Windows DLL should not be
referred to by MIimportedModules
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: [email protected]
Reporter: [email protected]
An instance of ModuleInfo contains an array of the ModuleInfo's for imported
modules. The purpose is to ensure the static constructors of imported modules
are run before the static constructor of the module with the ModuleInfo.
However, when a DLL is loaded, its DllMain is called, which then calls the
DLL's static initialization functions. So, already, all those constructors are
already called. There can be no further initialization order dependency of the
EXE's static constructors on the DLL's static constructors.
Hence, the ModuleInfo's of a module imported from a DLL should not be listed in
the ImportedModules of the EXE module.
But suppose the DLL depends on the EXE's static constructors being run first?
Or if two DLLs have mutually dependent static constructors? I don't see any
good way to resolve this, and in fact, if DLLs and EXEs are set up that way, it
sounds like a failed attempt at encapsulation.
See also:
https://issues.dlang.org/show_bug.cgi?id=23177
--
