VarDec and VarAss refactor (old) #11

New Issue

deavmi · 2022-10-15T15:41:33+01:00

deavmi commented

2022-10-15 15:41:33 +01:00

It doesn't make sense that we generate code which amounts to:

varDec -> (depends on) varAss

Firstly, this is what made us require that stupid swapping stuff.

Secondly, it's WRONG, varAss should depend on varDec.

Implementation

Changes to `dependency/core.d`

We currently visit the VarDec first, we then varDecNode = pool(VarDec). What we should then do, as we have a check for assignment existence is:

if(varDec.hasAssignment())
{
	/* Extract varAss and pool */
    varAssNode = pool(varAss);
    
    /* Now what we do (with `node` being the module or class or whatever) */
    node.needs(varAssNode);
    
    /* Now we make this variable's assignment dependent on the variable declaration */
    varAssNode.needs(varDecNode);
}

The resulting dependency tree would look like:

simple_class_ref.testValue (assignment)
	(S) simple_class_ref.testValue

Instead of (the wrong one):

(S) simple_class_ref.testValue
	simple_class_ref.testValue (assignment)

Changes to `typecheck/core.d`

Now linearizer would visit this graph and take eahc left-most node. Leaving us with the following linearization:

[(S) simple_class_ref.testValue, simple_class_ref.testValue (assignment)]

Which requires no swapping which is EXACTLY what we want and make more sense than what we are currently doing.

It doesn't make sense that we generate code which amounts to: ``` varDec -> (depends on) varAss ``` **Firstly**, this is what made us require that stupid swapping stuff. **Secondly**, it's **WRONG**, `varAss` should depend on `varDec`. --- ### Implementation #### Changes to `dependency/core.d` We currently visit the `VarDec` first, we then `varDecNode = pool(VarDec)`. What we should then do, as we have a check for assignment existence is: ```d if(varDec.hasAssignment()) { /* Extract varAss and pool */ varAssNode = pool(varAss); /* Now what we do (with `node` being the module or class or whatever) */ node.needs(varAssNode); /* Now we make this variable's assignment dependent on the variable declaration */ varAssNode.needs(varDecNode); } ``` The resulting dependency tree would look like: ``` simple_class_ref.testValue (assignment) (S) simple_class_ref.testValue ``` Instead of (the wrong one): ``` (S) simple_class_ref.testValue simple_class_ref.testValue (assignment) ``` #### Changes to `typecheck/core.d` Now linearizer would visit this graph and take eahc left-most node. Leaving us with the following linearization: ``` [(S) simple_class_ref.testValue, simple_class_ref.testValue (assignment)] ``` Which requires no swapping which is EXACTLY what we want and make more sense than what we are currently doing.

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

deavmi self-assigned this 2022-10-15 15:41:48 +01:00

deavmi started working 2022-10-15 15:41:52 +01:00

deavmi added the

typing

dependency

labels 2022-10-15 15:45:46 +01:00

deavmi stopped working 2022-10-15 15:47:27 +01:00

5min 35s

deavmi added the

needsfix

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

deavmi commented

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

Test case 1

Given the following code:

module simple_variables;


int x = 1;
int y = 2;

We now, as of commit 31c52c0bebeb77e36155e3c62f5fb3d7a7ed7707 on branch vardec_varass_dependency we now get the following output after some changes:

simple_variables.x (assignment)
         [expression: [numberLiteral: 1]]
         (S) simple_variables.x
simple_variables.y (assignment)
         [expression: [numberLiteral: 2]]
         (S) simple_variables.y

The code queue looks VERY CORRECT:

[INFO] 1/4: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_variables.x]
[INFO] 2/4: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_variables.x, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 1, Length: 4]]
[INFO] 3/4: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_variables.y]
[INFO] 4/4: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_variables.y, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 2, Length: 4]]

Which looks correct 👍

### Test case 1 Given the following code: ```d module simple_variables; int x = 1; int y = 2; ``` We now, as of commit `31c52c0bebeb77e36155e3c62f5fb3d7a7ed7707` on branch `vardec_varass_dependency` we now get the following output after some changes: ``` simple_variables.x (assignment) [expression: [numberLiteral: 1]] (S) simple_variables.x simple_variables.y (assignment) [expression: [numberLiteral: 2]] (S) simple_variables.y ``` The code queue looks **VERY CORRECT**: ``` [INFO] 1/4: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_variables.x] [INFO] 2/4: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_variables.x, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 1, Length: 4]] [INFO] 3/4: [Instruction: compiler.codegen.instruction.VariableDeclaration:varName: simple_variables.y] [INFO] 4/4: [Instruction: compiler.codegen.instruction.VariableAssignmentInstr:assignTo: simple_variables.y, valInstr: [Instruction: compiler.codegen.instruction.LiteralValue:Data: 2, Length: 4]] ``` Which looks correct 👍

deavmi referenced this issue

2022-10-15 16:38:49 +01:00

Class static initialization incorrect ordering #8

deavmi referenced this issue

2022-10-15 16:40:04 +01:00

Class static initialization incorrect ordering #8

deavmi referenced this issue

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

Clean ups #13

deavmi added a new dependency 2022-10-15 20:58:52 +01:00

#13 Clean ups

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

#10 VariableExpression recursive path initialization

deavmi commented

2022-12-19 09:47:50 +00:00

I think I will be closing this soon as I realised that the addInstr()/addInstrB()` and non-embedding was what was causing typechecker issues.

See #66

I think I will be closing this soon as I realised that the `addInstr()/`addInstrB()` and non-embedding was what was causing typechecker issues. See #66

deavmi added the due date 2022-12-19

2022-12-19 09:48:17 +00:00

deavmi commented

2022-12-19 09:49:08 +00:00

We can examine the whole issue #10 later, as it is not for the basics milestone.