Invalid record subtype relation about nballerina HOT 5 CLOSED

Record types are supposed to be normalized by sorting the field names, since field order shouldn't affect the type.

from nballerina.

ballerina-platform/ballerina-release#2337 should be reverted once this is fixed.

from nballerina.

It turned out the bug was not related to memoization. The culprit is mappingInhabited().

In the two cases where T74 and T75 are at the bottom [1] vs the top [2], we have the same posList with a single atom for T74 and negList with two atoms for T75, T315. However, the negList order is different in the two cases.

• In case [1] (which gives the correct result):

posList: T74, negList: T75, T315
In the first round at mappingInhabited(), T74 gets canceled out by the T75 thus exiting early saying mapping formular is empty.

• In case[2] (which gives the wrong result):

posList: T74, negList: T315, T75
In the first round at mappingInhabited(), T74 does not get canceled out by the T315 thus it goes for another round. In this logic, we go back and forth for negAtom being T315 and T75 eventually resulting in the wrong result.

from nballerina.

In the case[2], mappingInhabited() turned to be behaved as intended. However, the problem seems to be caused by the pairing.

In the initial sample, replacing "X" with "x" gets the test passed.

For record {| T a; 65 X; |} and record {| int:Signed8 X; |} pairing algorithm returns following in its first iteration,

• name: "X"
• posType: T
• negType: int:Signed8

The reason is it expects the record fields to be in sorted ascending order.

from nballerina.

ballerina-platform/ballerina-release#2337 should be reverted once this is fixed.

Reverts with ballerina-platform/ballerina-release#2339

from nballerina.