Tested on dmd.2.071.1.windows and dmd.2.071.2-b3.windows. Marked as blocker as it means Binderoo can't support forward referenced pointers as is common in the C++ codebases it is trying to auto-bind.
Problem is really simple to reproduce in an isolated environment. Add two modules like this in a program:
someclass.d:
module someclass;
import someotherclass;
struct SomeClass
{
SomeOtherClass* pSomeOtherClass;
}
shared static this()
{
someClassName = SomeClass.stringof;
}
__gshared string someClassName;
someotherclass.d:
module someotherclass;
import someclass;
struct SomeOtherClass
{
SomeClass* pSomeClass;
}
shared static this()
{
someOtherClassName = SomeOtherClass.stringof;
}
__gshared string someOtherClassName;
Output at runtime:
object.Exception@src\rt\minfo.d(167): Aborting: Cycle detected between modules with shared ctors/dtors:
someclass* ->
someotherclass* ->
someclass
Execution subsequently does not reach main.
Expected result:
Program initialises correctly and executes as expected.
Comment #1 by dfj1esp02 — 2016-09-13T16:30:46Z
Can't the name be immutable?
immutable string someOtherClassName = SomeOtherClass.stringof;
Comment #2 by gooberman — 2016-09-13T16:34:13Z
It is purely for illustrative/example purposes. The data I'm using cannot be immutable.
Comment #3 by doob — 2016-11-18T10:30:09Z
Can you show a more extended example(In reply to Ethan Watson from comment #2)
> It is purely for illustrative/example purposes. The data I'm using cannot be
> immutable.
Can you show a more extended example because the above example can be solved by directly initializing the variable:
__gshared string someOtherClassName = SomeOtherClass.stringof;
Comment #4 by gooberman — 2016-11-18T11:02:13Z
Of course it can be solved by assigning this specific string at compile time. Because you remove the shared static constructor.
Replace the contents of the constructor with a writeln and delete the gshared storage. Done. The point is the static constructor and the invalid cyclic dependency between pointers.
No, seriously. That's two people now to have commented on the most irrelevant part of the bug. The title of this bug explains exactly what's wrong.
Comment #5 by schveiguy — 2016-11-18T14:27:31Z
The issue is simply that you have a cycle. Forward referencing has nothing to do with it.
Unfortunately, this is functioning as designed. Martin has some ideas to make this possibly work, but those haven't been implemented yet. See https://issues.dlang.org/show_bug.cgi?id=16673
Comment #6 by uplink.coder — 2016-11-24T02:15:26Z
In this case the cycle is non-harmful.
Since no run-time initialized data is used.
We can and should improve the cycle-check.
Preferably in DMD itself, when possible.
I am having a look.
Comment #7 by dfj1esp02 — 2016-11-24T12:58:42Z
If it didn't use runtime data, it could be computed at compile time.
Comment #8 by schveiguy — 2016-11-25T15:24:32Z
(In reply to uplink.coder from comment #6)
> In this case the cycle is non-harmful.
> Since no run-time initialized data is used.
Yes, that is what issue 16673 is about -- using statically available data should not add a dependency.
Comment #9 by robert.schadek — 2024-12-07T13:36:56Z