On Wednesday, 30 May 2018 at 18:49:40 UTC, Steven Schveighoffer
wrote:
On 5/30/18 11:50 AM, Stefan wrote:
On Wednesday, 30 May 2018 at 13:26:53 UTC, Steven
Schveighoffer wrote:
On 5/30/18 8:09 AM, DigitalDesigns wrote:
... it's really really hard to make it check real
dependencies.
For serious dependency checking, you could try
https://github.com/funkwerk/depend.
It's used in quite large commercial projects.
OK, so a couple things:
1. The cycle checking has to be really really fast, and run in
a small amount of memory. It runs on startup of EVERY D
program. I would LOVE to get rid of this problem, but unless we
either invent our own object/linker system, or create some
tools to work on the linked binary, we have to do this.
2. The cycle algorithm is fast and works correctly, given the
dependencies that the compiler has provided. It's really not
the cycle algorithm that is the problem, but the determination
of dependencies. In other words, the problem is the compiler
not tracing all the actual dependencies and outlining that in
some structure to be parsed later during program startup.
As you increase the number of dependency points, and therefore
the graph size, the cycle algorithm has to take longer to
figure out if there are any cycles. So even if we can fix the
problem outlined here, the cost may not make it worth the
effort!
There are some ideas Martin and I have fleshed out a bit, which
would help reduced the cyclic dependencies, but so far, nobody
has had the time and/or skills to implement. For instance:
https://issues.dlang.org/show_bug.cgi?id=16265
https://github.com/dlang/druntime/pull/1602#issuecomment-231527759
-Steve
Why is this a runtime issue? It is not as if the execution of
static this are non-deterministic. The compiler and linker must
order the calls in some way. Maybe this is what you mean by own
object/linker? But even then, they would only have to be checked
once so why check every time the exe is ran when once it is ran
it must remain statically oriented for all future.
two exe's could be produced, one with only the static this code
which is ran after linking and verified, if doesn't pass then a
linker error is thrown.
These methods could be used for better alternatives but the real
issue is dependencies of static constructors.
How bout instead require the user to deal with it? The user can
specify the order to run and the compiler just blindly obeys.
pragma(cycle, 1)
static this()
{
}
...
pragma(cycle, 2)
static this()
{
}
It could require cycle to be unique or just share and let the
compiler do what it wants(assumes no cycles).
This gives the programmer a fix but doesn't assume there are
cycles, which most times there are not.
Later on, more intelligent cycle detecting code can be created
and added and then can give a warning in which the user can go
back and add the pragmas.
Alternatively, only require the pragmas on modules that
cyclically import each other. Even if their is no cycle, the
programmer just adds a pragma to satisfy the compiler/linker/rt.
