cycle dependencies

[Steven Schveighoffer]

On 6/1/18 11:42 AM, Neia Neutuladh wrote:
> On Friday, 1 June 2018 at 12:50:31 UTC, Steven Schveighoffer wrote:
>>> A fly in the ointment is .di files. This works today and does the 
>>> right thing:
>>
>> This actually is not a problem, because the dependency tree doesn't 
>> depend on whether the imported module has static ctors. It's how this 
>> works today -- each module only knows whether the modules has static 
>> ctors, and what imports it has. It doesn't go further than that.
> 
> Thanks to .di files, when I compile my executable, I don't always know 
> which modules import which other modules. That was half the point of my 
> example.

The .di file is just an interface, it doesn't know what's actually 
compiled in the binary.

To put it another way, the compiler only generates a ModuleInfo (or 
dependency modules) for .d files. .di files are simply a public API for 
the .d files.

> Are you talking about giving the initialization order for a subset of 
> modules? Because that wouldn't give much of a speed increase. Or do you 
> need all of your dependencies to have their own dependency order, and 
> the compiler can concatenate them?

Speed is one aspect, but the more important aspect is to do more 
fine-grained dependency tracking. Doing it on a function level vs. 
simply assuming all things in the module depend on all things in the 
dependent modules, allowing for instance module cycles where there is no 
real cycle between the data initialized. That's not going to work well 
with today's mechanisms because it would be much more expensive both in 
runtime and memory usage, and even further highlight the drawback that 
we are solving the same static problem on every run of a program.

> As an alternative, you could produce the initialization order by running 
> the program and seeing what order it uses.

Yes, but this still involves pushing all the dependency data into the 
binary. All we should care about at runtime is the order to execute 
ctors. We could even eliminate the needless storage of all the 
dependency modules that is there now.

-Steve