Ayaz Hafiz 1460f60ab1 Unify material recursion variables behind aliases and opaques ... 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		2022-07-29 11:03:47 -04:00
..
generated	Unify material recursion variables behind aliases and opaques	2022-07-29 11:03:47 -04:00
src	Don't add path instructions for newtypes that decay into their args	2022-07-21 14:57:17 -04:00
Cargo.toml	moved all crates into seperate folder + related path fixes	2022-07-01 17:37:43 +02:00