mirror of
https://github.com/roc-lang/roc.git
synced 2025-08-03 11:52:19 +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
615 B
Text
19 lines
615 B
Text
procedure List.6 (#Attr.2):
|
|
let List.385 : U64 = lowlevel ListLen #Attr.2;
|
|
ret List.385;
|
|
|
|
procedure Num.19 (#Attr.2, #Attr.3):
|
|
let Num.259 : U64 = lowlevel NumAdd #Attr.2 #Attr.3;
|
|
ret Num.259;
|
|
|
|
procedure Test.0 ():
|
|
let Test.1 : List I64 = Array [1i64, 2i64];
|
|
let Test.7 : U64 = 5i64;
|
|
let Test.8 : U64 = 4i64;
|
|
let Test.5 : U64 = CallByName Num.19 Test.7 Test.8;
|
|
let Test.6 : U64 = 3i64;
|
|
let Test.3 : U64 = CallByName Num.19 Test.5 Test.6;
|
|
let Test.4 : U64 = CallByName List.6 Test.1;
|
|
dec Test.1;
|
|
let Test.2 : U64 = CallByName Num.19 Test.3 Test.4;
|
|
ret Test.2;
|