mirror of
https://github.com/roc-lang/roc.git
synced 2025-09-26 13:29:12 +00:00
1460f60ab1
Even if there are no changes to alias arguments, and no new variables were introduced, we may still need to unify the "actual types" of the alias or opaque! The unification is not necessary from a types perspective (and in fact, we may want to disable it for `roc check` later on), but it is necessary for the monomorphizer, which expects identical types to be reflected in the same variable. As a concrete example, consider the unification of two opaques P := [Zero, Succ P] (@P (Succ n)) ~ (@P (Succ o)) `P` has no arguments, and unification of the surface of `P` introduces nothing new. But if we do not unify the types of `n` and `o`, which are recursion variables, they will remain disjoint! Currently, the implication of this is that they will be seen to have separate recursive memory layouts in the monomorphizer - which is no good for our compilation model. Closes #3653
19 lines
649 B
Text
19 lines
649 B
Text
procedure List.4 (List.101, List.102):
|
|
let List.387 : U64 = 1i64;
|
|
let List.386 : List I64 = CallByName List.70 List.101 List.387;
|
|
let List.385 : List I64 = CallByName List.71 List.386 List.102;
|
|
ret List.385;
|
|
|
|
procedure List.70 (#Attr.2, #Attr.3):
|
|
let List.389 : List I64 = lowlevel ListReserve #Attr.2 #Attr.3;
|
|
ret List.389;
|
|
|
|
procedure List.71 (#Attr.2, #Attr.3):
|
|
let List.388 : List I64 = lowlevel ListAppendUnsafe #Attr.2 #Attr.3;
|
|
ret List.388;
|
|
|
|
procedure Test.0 ():
|
|
let Test.2 : List I64 = Array [1i64];
|
|
let Test.3 : I64 = 2i64;
|
|
let Test.1 : List I64 = CallByName List.4 Test.2 Test.3;
|
|
ret Test.1;
|