VariableExpression recursive path initialization #10

New Issue

deavmi · 2022-10-13T15:00:25+01:00

deavmi commented

2022-10-13 15:00:25 +01:00

We need to recursively go down the path x.y.z and chop off and visit:

x.y.z
Init x
Init y
Init z

This is needed to be done in core.d in expressionPass() in dependency/.

We need to recursively go down the path `x.y.z` and chop off and visit: 1. `x.y.z` 2. Init `x` 3. Init `y` 4. Init `z` This is needed to be done in `core.d` in `expressionPass()` in `dependency/`.

deavmi added the

typing

label 2022-10-13 15:00:25 +01:00

deavmi self-assigned this 2022-10-13 15:00:25 +01:00

deavmi added this to the Dependency tree, type-checking and codegen project 2022-10-13 15:00:25 +01:00

deavmi commented

2022-10-13 15:01:18 +01:00

This should also statically initialize classes as well as we will visit the correct nodes. So we need this really.

deavmi commented

2022-10-13 17:49:53 +01:00

We need to get the order right because currently we might do a ClassStaticAllocate on x but make whatever the current dnode is require the class static allocation and we get a lot of wrongly order stuff somewhat.

We need to take a look at this.

Example input code:

module simple_class_ref;

class TestClass
{
    static int value = 2;
}

int testValue = TestClass.value;

Output dependency list:

[INFO] <<<<< FINAL CODE QUEUE >>>>>
[INFO] 1/6: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4]
[INFO] 2/6: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_class_ref.TestClass.value, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 2, Length: 4]]
[INFO] 3/6: [Instruction: compiler.codegen.instruction.ClassStaticInitAllocate:classStaticInitAllocate: simple_class_ref.TestClass]
[INFO] 4/6: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_class_ref.TestClass.value]
[INFO] 5/6: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_class_ref.testValue]
[INFO] 6/6: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_class_ref.testValue, valInstr: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4]]

It seems partially right actually, the last two make sense, declare and assign only once the above "init shananigans" is done. It is this "init shananigans" which we need to fix (re-order).

We need to get the order right because currently we might do a `ClassStaticAllocate` on `x` but make whatever the current dnode is require the class static allocation and we get a lot of wrongly order stuff somewhat. We need to take a look at this. --- Example input code: ```d module simple_class_ref; class TestClass { static int value = 2; } int testValue = TestClass.value; ``` Output dependency list: ``` [INFO] <<<<< FINAL CODE QUEUE >>>>> [INFO] 1/6: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4] [INFO] 2/6: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_class_ref.TestClass.value, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 2, Length: 4]] [INFO] 3/6: [Instruction: compiler.codegen.instruction.ClassStaticInitAllocate:classStaticInitAllocate: simple_class_ref.TestClass] [INFO] 4/6: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_class_ref.TestClass.value] [INFO] 5/6: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_class_ref.testValue] [INFO] 6/6: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_class_ref.testValue, valInstr: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4]] ``` It seems partially right actually, the last two make sense, declare and assign only once the above "init shananigans" is done. It is this _"init shananigans"_ which we need to fix (re-order).

deavmi commented

2022-10-13 17:57:22 +01:00

I wonder, for re-ordering we may need to tag things with some rolling count. It's easy enough re-ordering when we have to for example flip VarAssign and VarDec because they logically appear next to each other. But now we would probably have to flip a lot and we need a way to relate it I think 🤔

I wonder, for re-ordering we may need to tag things with some rolling count. It's easy enough re-ordering when we have to for example flip `VarAssign` and `VarDec` because they logically appear next to each other. But now we would probably have to flip a lot and we need a way to relate it I think 🤔

deavmi commented

2022-10-13 18:06:00 +01:00

Actually, the specific problem is that we are doing a ClassStaticAllocate midway an assignment expression (due to assigning a path containing a class, TestClass), almost like we need to make them float to the top somehow.

One thing to be fixed is:

[INFO] 1/2: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_class_ref.TestClass.value]
[INFO] 2/2: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_class_ref.TestClass.value, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 2, Length: 4]]
[INFO] sdfhjkhdsfjhfdsj 2
[INFO] typeCheckThing(): compiler.typecheck.dependency.classes.classStaticDep.ClassStaticNode

We should, when coming across the next: [INFO] 2/3: [Instruction: compiler.codegen.instruction.ClassStaticInitAllocate:classStaticInitAllocate: simple_class_ref.TestClass], is some sort of push back based on matching path names within our class with a static InitScope - and then stopping potentially.

Actually, the specific problem is that we are doing a `ClassStaticAllocate` midway an assignment expression (due to assigning a path containing a class, `TestClass`), almost like we need to make them float to the top somehow. One thing to be fixed is: ``` [INFO] 1/2: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_class_ref.TestClass.value] [INFO] 2/2: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_class_ref.TestClass.value, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 2, Length: 4]] [INFO] sdfhjkhdsfjhfdsj 2 [INFO] typeCheckThing(): compiler.typecheck.dependency.classes.classStaticDep.ClassStaticNode ``` We should, when coming across the next: `[INFO] 2/3: [Instruction: compiler.codegen.instruction.ClassStaticInitAllocate:classStaticInitAllocate: simple_class_ref.TestClass]`, is some sort of push back based on matching path names within our class with a static `InitScope` - and then stopping potentially.

deavmi commented

2022-10-13 18:08:35 +01:00

We should look at the placement of:

addInstrB(new ClassStaticInitAllocate(clazzName));

On line 678 of typecheck/core.d, that seems like a simple fix.

Also, double check the logic of the loop there, it might have bene reversed? As stuff looks reversed, check the usage of insert() on kept.insert() and the final for-loop at the end.

We should look at the placement of: ```d addInstrB(new ClassStaticInitAllocate(clazzName)); ``` On line 678 of `typecheck/core.d`, that seems like a simple fix. Also, double check the logic of the loop there, it might have bene reversed? As stuff looks reversed, check the usage of `insert()` on `kept.insert()` and the final for-loop at the end.

deavmi commented

2022-10-13 18:18:05 +01:00

Ah, we should be checking:

else if(cast(compiler.typecheck.dependency.variables.StaticVariableDeclaration)dnode)
{

The code for variables belonging to classes looks incomplete, no swapping like we see with the module code, so we should take a look at that before moving on.

I believe this plays a role, current problem is swapping but we have a order of:

[varAss, classStaticAllocate, varDec]

We end up swapping the first two, which is a problem, we need to search till we find a match.

Ah, we should be checking: ```d else if(cast(compiler.typecheck.dependency.variables.StaticVariableDeclaration)dnode) { ``` The code for variables belonging to classes looks incomplete, no swapping like we see with the module code, so we should take a look at that before moving on. --- I believe this plays a role, current problem is swapping but we have a order of: ``` [varAss, classStaticAllocate, varDec] ``` We end up swapping the first two, which is a problem, we need to search till we find a match.

deavmi commented

2022-10-13 18:36:01 +01:00

We need to recursively go down the path x.y.z and chop off and visit:

x.y.z

Init x

Init y

Init z

This is needed to be done in core.d in expressionPass() in dependency/.

I think this is still actually the problem - mmmh. I think when we do the ClassStaticInit we need to not break - mmmh.

> We need to recursively go down the path `x.y.z` and chop off and visit: > > 1. `x.y.z` > 2. Init `x` > 3. Init `y` > 4. Init `z` > > This is needed to be done in `core.d` in `expressionPass()` in `dependency/`. I think this is still actually the problem - mmmh. I think when we do the `ClassStaticInit` we need to not `break` - mmmh.

deavmi commented

2022-10-13 18:39:37 +01:00

We also may be generating too many expression chains in core/dependency.d, only one is needed.

This can be seen in:

[INFO] 1/5: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4]
[INFO] 2/5: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4]

Hence the need for reductive recursion.

We also may be generating too many `expression` chains in `core/dependency.d`, only one is needed. This can be seen in: ``` [INFO] 1/5: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4] [INFO] 2/5: [Instruction: compiler.codegen.instruction.FetchValueVar:fetchVarValName: simple_class_ref.TestClass.value, VarLen: 4] ``` Hence the need for reductive recursion.

deavmi commented

2022-10-13 18:51:33 +01:00

It seems to rear its ugly head with this darn expression (specifically VariableExpression) stuff as I add a lot of shit but should return one only actually, reduction recursion.

I should maintain some sort of deps list though as we go down and then clear once done (ONLY when doing VariableExpression with x.y.z). Then before returning at if(nearestDot == -1) we make that VariableNode .needs() each item in this deps list.

We can maintain a map of if we have:

x.y.z1
x.y.z2

Then z1 -> [deps list]
Then z2 -> [deps list]

It seems to rear its ugly head with this darn expression (specifically `VariableExpression`) stuff as I add a lot of shit but should return one only actually, reduction recursion. I should maintain some sort of deps list though as we go down and then clear once done (*ONLY* when doing `VariableExpression` with `x.y.z`). Then before returning at `if(nearestDot == -1)` we make that `VariableNode` `.needs()` each item in this deps list. We can maintain a map of if we have: 1. `x.y.z1` 2. `x.y.z2` Then `z1` -> _`[deps list]`_ Then `z2` -> _`[deps list]`_

👍 1

deavmi added the

dependency

needsfix

labels 2022-10-15 15:56:43 +01:00

deavmi referenced this issue

2022-10-15 20:58:40 +01:00

Clean ups #13

deavmi added a new dependency 2022-10-15 20:59:47 +01:00

#13 Clean ups

deavmi added a new dependency 2022-10-15 22:26:25 +01:00

#11 VarDec and VarAss refactor (old)