Bug 2457 – Detecting circular module dependencies at compile time

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Linux
Creation time
2008-11-15T16:58:23Z
Last change time
2024-12-13T17:49:02Z
Assigned to
No Owner
Creator
Neia Neutuladh
Moved to GitHub: dmd#17807 →

Comments

Comment #0 by dhasenan — 2008-11-15T16:58:23Z
I've been getting a lot of runtime errors about circular module dependencies. It'd save me some time if the compiler could detect at least some of these. The runtime doesn't have a chance of giving a reasonable error message, but the compiler could. At the very least, it'd save some time.
Comment #1 by gide — 2008-11-16T11:08:05Z
Without example code it is unlikely that this will get fixed. Add the code which is failing and include the compilation options you are using. Extra points will be awarded for making the failing code as short as possible.
Comment #2 by jarrett.billingsley — 2008-11-16T13:54:09Z
====[a.d]==== module a; import b; static this(){} void main(){} ====[b.d]==== module b; import a; static this(){} ====[Command line]==== $ rebuild a $ ./a object.Exception: Cyclic dependency in module a $ Pretty short. It makes no sense that the compiler would output an executable that will always cause a runtime error. The compiler knows that there is a circular module dependency, and should be able to issue an error at compile time. Note, however, that in this case there _is_ no circular dependency. Even though the modules are circularly imported and both have static constructors, the static constructors do not depend on the other module. This _should_ be legal, at least semantically. That the program issues an error means that the compiler and runtime aren't doing a whole lot of analysis to determine that there is a cyclic dependency. It's a false positive.
Comment #3 by smjg — 2008-11-16T19:02:05Z
An interesting concept. The only reason I can see for this being a runtime failure is that the module dependencies are analysed at runtime to determine the order in which to run static constructors. But why? This process should be in the compile time. Then not only can it report any circular dependency problems during compilation, but it can also attempt to resolve any apparent circularity by examining what the static constructor itself depends on (directly or indirectly).
Comment #4 by robert.schadek — 2024-12-13T17:49:02Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17807 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB