Experiment with scopes

[mar9000]

I've made some experiments with scopes, but I'm still not getting to point... probably.
What I've tried is a RefExpr(context = RefExpr(context = CallExpr())), see below, so that the middle RefExpr change the type (from class_1 to class_0). In this case with the same symbol on both RefExpr they got resolved but AFAIK one of they should not.

The problem can probably be resolved with an if (context is RefExpr)... in the RefExpr scope but I'm feeling the code is getting weird this way.

This is the code I've added that results in no error where it should:

            ClassDecl(
                name = "class_1",
                features = mutableListOf(
                    FeatureDecl(
                        name = "feature_1_0",
                        type = ReferenceByName(name = "class_0"),
                    ),
                ),
                operations = mutableListOf(
                    OperationDecl(
                        name = "operation_1",
                        returns = ReferenceByName(name = "class_1"),
                        statements = mutableListOf(
                            AssignmentStmt(
                                lhs = RefExpr(
                                    context = CallExpr(
                                        operation = ReferenceByName(name = "operation_1"),
                                    ),
                                    symbol = ReferenceByName(name = "feature_1_0"),
                                ),
                                rhs = RefExpr(
                                    context = RefExpr(
                                        context = CallExpr(
                                            operation = ReferenceByName(name = "operation_1"),
                                        ),
                                        symbol = ReferenceByName(name = "feature_1_0"),
                                    ),
                                    symbol = ReferenceByName(name = "feature_1_0"),   // <-- it resolves but should not resolve
                                ),
                            ),
                        ),
                    ),
                ),
            ),

Whereas it fires an error with the right field name:

                                 symbol = ReferenceByName(name = "feature_0"),   // <-- should resolve but fires an error

[ftomassetti]

First of all, thank you for looking in Kolasu!
Is there a place where I can see the whole code? I would be happy to help you debug it.
Symbol Resolution is something that we worked on recently and perhaps there is some issue to solve

[mar9000]

I can prepare a test/fork for you... as soon as I have time. Nevertheless it's simple: it's just to change this line:

kolasu/core/src/test/kotlin/com/strumenta/kolasu/symbolresolution/DeclarativeLocalSymbolResolverTest.kt

Line 143 in cbb18f9

ClassDecl("class_1"),

with the code I've posted above, and run the test. It runs without problem but AFAIK it should not.

What I mean is that operation_1 returns class_1, so you can reference (inner RefExpr) feature_1_0. But now class_1.feature_1_0 type is class_0, you cannot reference again feature_1_0 (outer RefExpr).

[mar9000]

Here you are
https://github.com/mar9000/kolasu/blob/master/core/src/test/kotlin/com/strumenta/kolasu/symbolresolution/DeclarativeLocalSymbolResolverTest.kt

I've added 2 tests, both fail but I think both should pass instead.

[ftomassetti]

Thank you Marco, I appreciate this!
I studied the problem, but I cannot solve it. I will ask my colleague @loradd , who wrote this new symbol resolution mechanism, to take a look when he is back from vacation. Thank you for your patience, this is something we released recently and probably there are still a few bits to double check

[loradd]

Thank you @mar9000! The original idea of the symbol resolution API was to provide support for solving references without considering the semantics of a given language, e.g. resolve a feature without checking whether or not this is semantically correct. According to this, the correctness of the resolved symbols could be verified by navigating the AST in some subsequent step. I am looking into this now and preparing a change proposal for the API to also support cases where users want to specify such semantics inside the symbol resolver, i.e. in the corresponding scopeFor. I will get back at this scenario asap, thank you again!