Fixing cyclic import static construction problems

[Jonathan M Davis]

On Friday, November 30, 2012 10:27:31 Artur Skawina wrote:
> On 11/29/12 23:34, Jonathan M Davis wrote:
> > On Thursday, November 29, 2012 23:28:07 Timon Gehr wrote:
> >> On 11/29/2012 01:17 PM, Jonathan M Davis wrote:
> >>> In the past when I've brought up similar solutions, he's been completely
> >>> opposed to them. ...
> >> 
> >> It is not a solution, it is a workaround.
> > 
> > What do you mean? The runtime sees circular dependencies between modules
> > even when there's no actual circular dependency between static
> > constructors. We need to fix that. One way is to just make the runtime
> > not care, which wouldn't be particularly safe. Another is to explicitly
> > tell it that there are no such dependencies. I don't see how that's not a
> > solution. And unless someone can come up with a way for the runtime to
> > somehow determine on its own that there's no actual, circular dependency,
> > I don't see how anything better could be done.
> 
> It's relatively easy for the /compiler/ to figure it out; it's just that
> implementing a simple user-provided flag requires the least amount of work.
> What Walter suggested can be tweaked to be sane (per-ctor flag) and will
> still be useful if/when the compiler becomes smarter (think lazily initted
> module fields).
> For the compiler to check if the value of every imported symbol accessed
> inside a mod-ctor can be evaluated at compile-time (if you encounter a case
> where this is not true it means there (potentially) is a true dependency and
> the ctors should be ordered) would require more work.

It can't be evaluated at compile time because of .di files. The compiler 
doesn't necessarily have all of the source to work with - including the static 
constructors - and if it doesn't have that, it can't do it. If anything figures 
this out automatically, it has to be the runtime. If we can do that, great, 
but it means that it'll have actually have to look at individual symbols 
rather than just at the module level like it's doing now, and right now, we 
have nothing even close to that. Regardless, while the compiler may be able
to provide additional information to the runtime, it's still the runtime that
needs to figure this out and not the compiler.

- Jonathan M Davis