[Improvement]: Reorder top level node list

[chiranSachintha]

Description

In the existing implementation, we currently reorder the constants list and the global variable list separately. However, when considering the annotations of type definitions(as annotations are part of the typedesc), they depend on the order of both constants and global variables. Therefore, it is necessary to reorder the toplevel node list instead of reordering constants, global variables, and type definitions separately.

type AnnotRecord record {|
    string value;
|};

annotation AnnotRecord annot on type;

@annot {
    value: l
}
type T1 record {
    string name;
};

string l = "chiranS";

When considering the above example, the annot (annotation) is a component of the type description (typedesc) of T1. So we need to rearrange the top-level node list as follows.

type AnnotRecord record {|
    string value;
|};

annotation AnnotRecord annot on type;
string l = "chiranS";
@annot {
    value: l
}
type T1 record {
    string name;
};

Describe your problem(s)

No response

Describe your solution(s)

No response

Related area

-> Compilation

Related issue(s) (optional)

No response

Suggested label(s) (optional)

No response

Suggested assignee(s) (optional)

No response

[rdulmina]

The above example in the issue works without any issue in the current implementation because although the l is defined after the type T1, when we codegen we populate the annotation value for type T1 after all the const and var declarations are done. We handle this in the AnnotationDesugar Hence the above sample works without any issue.

Issue in the current approach is when we have access the annot value before the populate happens

type AnnotRecord record {|
   string value;
|};

annotation AnnotRecord annot on type;

@annot {
   value: l
}
type T1 record {
   string name;
};

string l = "chiranS";
string? b = T1.@annot?.value;

Note that variable b is a top-level variable. The value of the b will be null in this case. If we define b locally it gives the correct value

[rdulmina]

Changes are done. 13 jballerina unit tests are filing ATM. Will send a PR soon. Below are some failing cases.

1. The below sample fails with java.lang.NullPointerException: Cannot read field "name" because "varDcl" is null

public function main() {
    var input = [{name: "Saman", price: 11}];
    record {|string name; int price;|}[][] res = from var {name} in input group by name
                                                    select from var {price} in input
                                                            select {name, price};
// the issue here is we create several lambda functions for the query expression and those functions 
// do not have the typedesc in local variables. it seems typedesc need to be passed as a closure for those
}

2. Set of test are failing causing method to large error.