cycle dependencies

[Steven Schveighoffer]

On 5/31/18 8:49 PM, Neia Neutuladh wrote:
> On Thursday, 31 May 2018 at 23:17:20 UTC, Steven Schveighoffer wrote:
>> Hm... I just had a crazy idea: what if D had a switch that allowed it 
>> to store a dependency graph of constructors into a json file, and then 
>> when you link, there is a wrapper which consumes all these files, runs 
>> the cycle detection and sort, and then compiles a perfectly sorted 
>> moduleinfo section to be included in the binary (obviously, written in 
>> D and compiled by the compiler).
> 
> This is how languages get custom object formats and custom linkers.

Yep. I know that this is something that we need to be wary of. The 
proposed file format, however, would not be something like an object or 
even a linker, just a text file that hints in how to link these together 
without having to do the sort.

> 
> 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.

The dependency file would keep this same mechanism, we wouldn't be doing 
more interpretation.

> If the dependency data were inserted into the object files instead 
> (which it should be? that's what ModuleInfo is), then the compiler could 
> potentially read this out before linking, and we could be sure that the 
> resulting order is correct. Like, insert a weak symbol into each normal 
> object file saying there's no dependency graph, and then the compiler 
> can run on a set of object files to produce a new object file with the 
> complete dependency graph as a strong symbol.

It's an interesting idea, the only benefit really being to avoid having 
separate files for the data. I don't know enough about object files to 
be able to speak coherently about it.

I have a much better feeling, however, about having a more 
readable/understandable file format than object files. It's definitely a 
lot easier to deal with something like a JSON file than an object file.

> But that's more work.

There's nothing in this proposal that is less than a lot of work :) So 
putting a bit more on top is OK, if it makes things more useable.

This isn't something to flesh out buried in a sub-thread anyway. I'm 
going to put together a more complete description and proposal. Not a 
DIP yet, because I want to gauge interest first.

-Steve