• d-bugmail puremagic.com (28/28) May 19 2006 http://d.puremagic.com/bugzilla/show_bug.cgi?id=147
• BCS (46/60) May 20 2006 Several thoughts on this issue.

d-bugmail puremagic.com writes:

http://d.puremagic.com/bugzilla/show_bug.cgi?id=147

           Summary: circular imports break with -cov
           Product: D
           Version: 0.156
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: shro8822 uidaho.edu


With or without the -cov option, this compiles. However, the version with
–cov fails at _runtime_ with a circular reference error of some type.

<code file=a.d>
import b;
void main(){}
</code>

<code file=b.d>
import a;
</code>

thoughts:
--This should be detected at compile/link time (or maybe that’s no possible).
--There should be some way to control initialization loops. (how?)


tested on linux, assumed on others

originally reported back in Jan '06
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/6059.html


-- 

BCS <BCS_member pathlink.com> writes:

Several thoughts on this issue.


Considering that this error is generated at runtime, their must be some sort of
runtime dependency resolver (something like "make") that uses stored dependency
information to determine the call order. This suggests a solution to the -cov
problem. Seeing as ether of the modules can be -coved by its self, the -cov code
has no dependencies on the user code or other -cov code. Omitting these
dependencies from the stored information  would resolve the problem. 
To borrow make's syntax, the assumed dependencies  in the given code is as
follows. However the second dependency is fiction.

module.a.cov_init : global.cov_init  module.b.cov_init
module.b.cov_init : global.cov_init module.b.cov_init


More generally: why is it assumed that an import implies a static constrictor
dependency? I would expect that in the general case this is NOT true. I would
like to suggest that this behavior be changed.

One option would be to reverse it, e.i. dependancies must be explicitly stated
with something like "make" syntax (or whatever else Walter likes) . In the
following example b.static_this() would get called first.

<code file=a.d>
import b;

static this() : b {}
// a.static_this() depends on b.* being up and running
</code>

<code file=b.d>
import a;

static this() {}
// a.static_this() does _not_ depend on a.*
</code>

Another option would be to set the rules so that a static constructor depends
only on imports lexically before it in the module. To do the same thing as
above, one would code:

<code file=a.d>
import b;

static this() : b {}
// a.static_this() depends on b.* being up and running
</code>

<code file=b.d>
static this() {}
// a.static_this() does _not_ depend on a.*

import a;
</code>


anyway just a butch of thoughts.

In article <bug-147-3 http.d.puremagic.com/bugzilla/>, d-bugmail puremagic.com
says...
http://d.puremagic.com/bugzilla/show_bug.cgi?id=147

           Summary: circular imports break with -cov

[...]
With or without the -cov option, this compiles. However, the version with
-cov fails at _runtime_ with a circular reference error of some type.

<code file=a.d>
  import b;
  void main(){}
</code>

<code file=b.d>
  import a;
</code>

thoughts:
--This should be detected at compile/link time (or maybe that's not possible).
--There should be some way to control initialization loops. (how?)