[Issue 4384] New: Cyclic dependency check for modules is broken

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Jun 24 07:07:18 PDT 2010


http://d.puremagic.com/issues/show_bug.cgi?id=4384

           Summary: Cyclic dependency check for modules is broken
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: druntime
        AssignedTo: sean at invisibleduck.org
        ReportedBy: schveiguy at yahoo.com


--- Comment #0 from Steven Schveighoffer <schveiguy at yahoo.com> 2010-06-24 07:07:15 PDT ---
Example code that compiles/runs but results in undetermined behavior:

mod1.d:
public import mod2;
public import mod3;
import std.stdio;

void main()
{
    writefln("x = %d, y = %d", x, y);
}

mod2.d:
import mod1;

__gshared int x = 1;

static this()
{
    x = y;
}

mod3.d:
import mod1;

__gshared int y = 2;

static this()
{
    y = x;
}

The problem stems from the code assuming that an import with no static
ctors/dtors is "finished" after the first time it is encountered.  This is done
because "trivial" cycles are allowed, that is, cycles that involve only one
module with static ctors/dtors.  Such cycles are ok because a module can
trivially depend on itself or other modules without ctors/dtors.  However, when
a cycle requires going through such a module (sans ctor/dtor) twice as in the
above example, it will not be detected.

The logical way around this is to remove those nodes from the dependency graph,
forwarding all edges to incoming connections.  Such an algorithm would be an
O(n^2) task.  I don't know if there's a way to do this without creating a
separate table.  If the compiler could generate transitive dependencies, then
we could do this trivially by just skipping those modules.  But I'm pretty sure
that's can be impossible if the modules are not compiled together.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list