Standalone Variable Assignments global resolution bug #46

New Issue

deavmi · 2022-12-14T12:02:27Z

deavmi commented

2022-12-14 12:02:27 +00:00

Problem code:

We are currently failing the assertion of:

assert(tc.getResolver().resolveWithin(c, vAsStdAl.getVariableName()));

In dependency/core.d's generalPass():

/**
* Variable asignments
*/
else if(cast(VariableAssignmentStdAlone)entity)
{
	VariableAssignmentStdAlone vAsStdAl = cast(VariableAssignmentStdAlone)entity;

    /* Set the Context */
    vAsStdAl.setContext(context);

    /* TODO: CHeck avriable name even */
    gprintln("YEAST ENJOYER");


    // FIXME: The below assert fails for function definitions trying to refer to global values
    // as a reoslveBest (up) is needed. We should firstly check if within fails, if so,
    // resolveBest, if that fails, then it is an error
    assert(tc.getResolver().resolveWithin(c, vAsStdAl.getVariableName()));
    gprintln("YEAST ENJOYER");
    Variable variable = cast(Variable)tc.getResolver().resolveWithin(c, vAsStdAl.getVariableName());
    assert(variable);

Solution:

We should be using resoveBest(c, vAsStdAl.getVariableName()) as it can resolve upwards then for the cases where the assignment is to a variable not within the current container. For example, a global int k = 1 will fail to be lookedup when assigned to inside a COntainer like a Function as with:

int k = 1;

void myFunc()
{
	k=1;
}

This is because what happens is the generalPass() is done on the Function container and we are resolving within that, but not doing so and then (if a fail to resolve happens, let it resolve upwards).

Fix: Use resolveBest(). I cannot see why not currently - unsure why I did resolveWithin actually.

## Problem code: We are currently failing the assertion of: ```d assert(tc.getResolver().resolveWithin(c, vAsStdAl.getVariableName())); ``` In `dependency/core.d`'s `generalPass()`: ```d /** * Variable asignments */ else if(cast(VariableAssignmentStdAlone)entity) { VariableAssignmentStdAlone vAsStdAl = cast(VariableAssignmentStdAlone)entity; /* Set the Context */ vAsStdAl.setContext(context); /* TODO: CHeck avriable name even */ gprintln("YEAST ENJOYER"); // FIXME: The below assert fails for function definitions trying to refer to global values // as a reoslveBest (up) is needed. We should firstly check if within fails, if so, // resolveBest, if that fails, then it is an error assert(tc.getResolver().resolveWithin(c, vAsStdAl.getVariableName())); gprintln("YEAST ENJOYER"); Variable variable = cast(Variable)tc.getResolver().resolveWithin(c, vAsStdAl.getVariableName()); assert(variable); ``` ## Solution: We should be using `resoveBest(c, vAsStdAl.getVariableName())` as it can resolve upwards then for the cases where the assignment is to a variable not within the current container. For example, a global `int k = 1` will fail to be lookedup when assigned to inside a COntainer like a `Function` as with: ```d int k = 1; void myFunc() { k=1; } ``` This is because what happens is the `generalPass()` is done on the `Function` container and we are resolving within that, but not doing so and then (if a fail to resolve happens, let it resolve upwards). **Fix**: Use `resolveBest()`. I cannot see why not currently - unsure why I did resolveWithin actually.

deavmi self-assigned this 2022-12-14 12:05:05 +00:00

deavmi added the

dependency

label 2022-12-14 12:05:08 +00:00

deavmi added this to the Dependency tree, type-checking and codegen project 2022-12-14 12:05:11 +00:00

deavmi changed title from ~~Standalone Variable Assignments resolution bug~~ to Standalone Variable Assignments global resolution bug

2022-12-14 12:05:19 +00:00

deavmi added reference vardec_varass_dependency

2022-12-14 12:05:34 +00:00

deavmi commented

2022-12-14 13:01:20 +00:00

Next error: It seems is:

[ERROR] Cannot reference variable k which exists but has not been declared yet
tlang: Cannot reference variable k which exists but has not been declared yet
[debug-only] JCLI has displayed this exception in full for your convenience.
misc.exceptions.TError@source/tlang/misc/exceptions.d(15): Cannot reference variable k which exists but has not been declared yet

Makes sense seeing as the weighting of functions is to first delcare them then globals. This should be reversed. See issue #47.

Next error: It seems is: ``` [ERROR] Cannot reference variable k which exists but has not been declared yet tlang: Cannot reference variable k which exists but has not been declared yet [debug-only] JCLI has displayed this exception in full for your convenience. misc.exceptions.TError@source/tlang/misc/exceptions.d(15): Cannot reference variable k which exists but has not been declared yet ``` Makes sense seeing as the weighting of functions is to first delcare them **then** globals. This should be reversed. See issue #47.

deavmi referenced this issue

2022-12-14 13:09:08 +00:00

Circularity discussion #47

deavmi added a new dependency 2022-12-14 13:09:17 +00:00

#47 Circularity discussion

deavmi referenced this issue

2022-12-15 09:35:39 +00:00

Seperate DNode pools causing issues #48

deavmi commented

2022-12-16 13:01:21 +00:00

Actually, not weighting related. Firstly was related to the emit ordering.

Secondly, the resolveBest fix was needed but the context needed to be set correctly.

Lastly, all this stuff had been properly fixed in commit 2a12c310a66e42783a524cd58f040454c1c36197 on branch vardec_varass_dependency

Actually, not weighting related. Firstly was related to the emit ordering. Secondly, the `resolveBest` fix was needed but the context needed to be set correctly. Lastly, all this stuff had been properly fixed in commit `2a12c310a66e42783a524cd58f040454c1c36197` on branch `vardec_varass_dependency`

deavmi added the

emit

label 2022-12-16 13:01:25 +00:00

deavmi removed a dependency 2022-12-16 13:04:06 +00:00

#47 Circularity discussion

deavmi closed this issue

2022-12-16 13:05:30 +00:00

deavmi referenced this issue

2022-12-17 11:34:22 +00:00

Revert semantically incorrect VarAssStdAlone context set hack #57

deavmi added this to the Basics milestone 2022-12-17 17:12:19 +00:00

Sign in to join this conversation.