Revamp SymbolEnter to properly resolve constants

[SandaruJayawardana]

Description:
Related discussion - #35745

It is necessary to properly type check and resolve constants at the earliest possible stage, since constants may be required to resolve other variables, type defn etc.. According to the spec, constants are known at compile time and they can be only dependent on other constants or type definitions which are also known at compile time. Therefore, we can resolve constants at the SymbolEnter phase.

Describe your problem(s)
In the current implementation, compiler resolves the constants at ConstantValueResolver in semantic analyzer phase. But type nodes of module level variables are already resolved before resolving the constants. Therefore, even compiler updates the constants with correct types in later stage, it will not fix the module level usages (as a type) of the constants.

Describe your solution(s)
Will update once the approach is finalized.

Related Issues (optional):
#28334, #32804, #33890

[prakanth97]

Initially, there were 560 failed tests and approximately 1500 tests that were skipped. By addressing the unimplemented cases in the type resolver and constant type checker, we were able to reduce the number of failing unit tests to 65.

[prakanth97]

In the current constant type checker, when evaluating the const-expr the expected type of the module-const-decl is not considered. Due to that it violates below case.

// According the spec, 
// type of `1` is float and type of `2.0` is float. hence it is valid.
const float|decimal X1 = 1 + 2.0;

// type of `2.0` is float but type of `3.0d` is decimal. hence it is not valid.
const float|decimal X2 = 2.0 + 3.0d;

// type of `2` is float but type of `2.0d` is decimal. hence it is not valid.
const float|decimal Z2 = 2 * 2.0d;

But according to the current implementation, all are valid cases. We are currently updating the constant type checker to handle these scenarios properly.

[prakanth97]

In the current constant type checker, when evaluating the const-expr the expected type of the module-const-decl is not considered. Due to that it violates below case.

// According the spec, 
// type of `1` is float and type of `2.0` is float. hence it is valid.
const float|decimal X1 = 1 + 2.0;

// type of `2.0` is float but type of `3.0d` is decimal. hence it is not valid.
const float|decimal X2 = 2.0 + 3.0d;

// type of `2` is float but type of `2.0d` is decimal. hence it is not valid.
const float|decimal Z2 = 2 * 2.0d;

But according to the current implementation, all are valid cases. We are currently updating the constant type checker to handle these scenarios properly.

This is fixed by rewriting the constant type checker to use expected type to determine the literal types instead of calculating all possible candidates.

[prakanth97]

To allow generic intersection we have to resolve effective type of intersection type definition using depth first approach. But there is a limitation when we have cyclic reference in the type definition.

type A object {
   B b;
   int a;
};

type B A & readonly;

When resolving B, type A is not resolved completely. So immutable clone will have the partially defined type. To solve this, first we have to calculate partially defined effective type for B. After fully defined the A we will visit type of B and update the effective type.

[prakanth97]

• All the existing langlib tests and unit-tests have passed.
• If the type definition is readonly intersection with inherently immutable type then we set the inherently immutable type as type of type definition to optimise the runtime.

Currently working on updating immutable type (effective type of readonly intersection) of tuple type.

type A [B];
type B A & readonly;
. . . . 
type A B & readonly;
type B [A]|int;
. . . .
type A [B] & readonly;
type B A|int;
. . . .
type A [B] & readonly;
type B [A]|int;

These are the few cyclic tuple case, where we have to update the improperly defined effective type.

I'm getting below runtime error for

type A [B] & readonly;
type B A|int;

Currently looking into why is it failing

java.lang.NoSuchFieldError: $type$A
                    at constants.$_typeref_type_constants.$populate$typeRefType$A(Unknown Source)
                    at constants.$_typeref_type_constants.$populate_typeref_types(Unknown Source)
                    at types.$_types.$createTypeConstants(Unknown Source)
                    at types.$_types.$createTypes(Unknown Source)
                    at $_init.$currentModuleInit(.)
                    at $configurationMapper.$initAndPopulateConfigData(Unknown Source)
                    at $configurationMapper.$configureInit(Unknown Source)

[prakanth97]

To allow generic intersection we have to resolve effective type of intersection type definition using depth first approach. But there is a limitation when we have cyclic reference in the type definition.

type A object {
   B b;
   int a;
};

type B A & readonly;

When resolving B, type A is not resolved completely. So immutable clone will have the partially defined type. To solve this, first we have to calculate partially defined effective type for B. After fully defined the A we will visit type of B and update the effective type.

• Record type, object type, union type are handled by implementing visitors to update immutable type.
• Related tests have passed.
• Need to implement visitors for other BTypes.

[prakanth97]

type C record {
    *B;
};

type A record {|
    B b;
    int a;
|};

type B A & readonly;

inclusion of cyclic record is not handled. We consider it as know issue and attend that later

[prakanth97]

For this case we are logging a compile-time error invalid usage of finite literal: duplicate key 'a'.

const x = "a";
const map<string> X = {a : "A", [x] : "B"};

[prakanth97]

class A {
    *B;
}

class B {
    *A;
}

This should result invalid cyclic reference error like record and object type definitions. Currently fixing it