cycle dependencies

Steven Schveighoffer schveiguy at yahoo.com
Wed May 30 13:26:53 UTC 2018


On 5/30/18 8:09 AM, DigitalDesigns wrote:
> Seriously stupid bug here!
> 
> I had an enum an static this() { } (empty, forgot why I added it) one 
> module and an struct in another module that converted values from the 
> enum. I imported only that enum and guess what?!?! Cycle dependency! 
> removed the static this() { } and worked!
> 
> The cycle dependency checking code is far too ignorant.

It is ignorant. It only checks for the presence of static constructors, 
not what they do. This is as designed -- there are too many ways for 
dependencies to leak between modules that it's really really hard to 
make it check real dependencies.

> It just blindly 
> checks without any rationale. Someone said this was because phobos had a 
> bug in it so the cycles were checked, maybe it's time to address that 
> issue rather than breaking code arbitrarily?
> 

I don't know what was said, but the cycle code was very broken 
originally. A few years ago, I fixed it, and then it was re-broken by 
accident, and I re-fixed it.

It should work properly now. But that has nothing to do with adding an 
empty static ctor, it had to do with properly detecting cycles.

The cycle detection functions as designed. You can disable it via DRT 
flags, but this means that there is no guarantee that they run in the 
proper order. The compiler would have to build a much more sophisticated 
dependency tree in order to do anything more clever, but I doubt it 
would ever be able to be perfect in detecting which things truly depend 
on one another.

-Steve


More information about the Digitalmars-d mailing list