I think this makes it easier to read type variables when they come from
flex/rigid vars with pre-existing names, just give them a number suffix
to differentiate them.
When we unify two variables that end up merged, the rank of the
resulting content is the lower of the two variables being merged. But
during storage, we really do mean, take the target descriptor of the
type we're merging against, and don't try to lower to a
possibly-generalized rank! This fixes a couple bugs I didn't even
realize were present!
During the unspecialized lambda set compaction procedure, we might end
up trying to merge too many disjoint variables during unspecialized
lambda unification. Avoid doing so, by checking if we're in the
compaction procedure.
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
Despite our best efforts, sometimes we still can't specialize lambda
sets on the fly, if a specialization lambda set's specialization type
isn't yet well-known! This commit adds an `AwaitingSpecializations`
data structure to keep track of the lambda sets blocked for
specialization behind a specialization's full resolution in the module.
After the specialization is resolved, its blocked lambda sets can be
eagerly compacted.
