Dependency generation

Tristan B. Kildaire

2021/08/11

Tags: typechecking dependency static oop tree

Working dependency generation (so far)

Just a quick update. I have started, I’d say about two months ago maybe, working on the dependency tree generaiton and it is working. This tree represents the order of initialization of entities and when completed in its construction it will be used for code generation simply by traversing down the tree.

Currently we parse the syntax tree generated by the parser and generate a new tree with components that contain a reflection or ressemblance rather to their syntactic counterpart but with more information, such as has the node been visited already etc.

An example of this is done if you checkout to the commit 06dbf479ffdfdfa7b2f314a6f2860c75e16bb52f on branch typecheck_refactor and run the following:

dub build --force
./tlang compile source/tlang/testing/typecheck/basic_dependence_correct1.t

This will run on the source file below:

module typeChecking1;

A aInstance;
B bInstance;
int k;

class A
{
    static int pStatic;
    static B bInstanceStatic;
    static A aInstanceStaticMoi;

    int poes;
}

class B
{
    static int jStatic;
    static A aInstanceStatic;
}

And will output the following:

bruh
      (S) typeChecking1.aInstance
         typeChecking1.A
            (S) typeChecking1.A.pStatic
            (S) typeChecking1.A.bInstanceStatic
               typeChecking1.B
                  (S) typeChecking1.B.jStatic
                  (S) typeChecking1.B.aInstanceStatic
            (S) typeChecking1.A.aInstanceStaticMoi
      (S) typeChecking1.bInstance
      (S) typeChecking1.k

Which if we look at it shows the correct initialization of that code. We first init the module (implicit so far). Then we see that aInstance needs to be declared, so we init it, as it is static, but because it refers to a class type, A, we must statically initialize that class too (initilizing its static entities). So we init typeChecking1.A (our class), as you can see we then initialize the pStatic, which needs no further initlaization, then we do bInstanceStatic, this must init class B, so we do that, but you see there would be a loop now, but because when we enter A for its static initlaization we set it as visited we know therefore it is busy initting and we should not re-init it (we are basically a dependency of it), then we init jStatic and return.

As you can see there is not dependency on bInstance on class B as it would have already been initted, and k didn’t require anything to be initted but itself.

More exmaples

There is another more complex example ending in 2, same test case directory.

>> Home