There have been multiple instances where I had the need to iterate over
type variables, only to discover that the traversal order is arbitrary.
This commit fixes that by adding SortedMapping, which utilizes BTreeMap
internally to guarantee a traversal order. All instances of VarMap are
now refactored to use this to ensure that type variables are iterated in
the order of its variable ID, which should be monotonically incremented
by the unifier.
For some reason, when unifying a function call parameter with an
argument, subsequent calls to the same function will only accept the
type of the substituted argument.
This affect snippets like:
```
def make1() -> C[Literal[1]]:
return ...
def make2() -> C[Literal[2]]:
return ...
def consume(instance: C[Literal[1, 2]]):
pass
consume(make1())
consume(make2())
```
The last statement will result in a compiler error, as the parameter of
consume is replaced with C[Literal[1]].
We fix this by getting a snapshot before performing unification, and
restoring the snapshot after unification succeeds.
Fixes nondeterministic error messages due to nondeterministic
unification order. As all unification operations will be restored, the
error messages should not be affected by the unification order before
the failure operation.
Previously, we have to copy types from one unification table to another,
and make the table sendable. This requires cloning (processing) the
whole table 3 times per function call which is not efficient and uses
more memory than required when the unification table is large.
We now use a concrete type table to only copy the type we need. This
reduces the overhead as we only need to process the unification table
for once (when we do the function codegen), and reduces memory usage by
a bit (but not noticeable when the unification table is small, i.e. the
types are simple).
David Mak
Sebastien Bourdeauducq
ychenfo
wylited
pca006132