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.
Replaces the previously-used `DeferredObligations` structure used for
accumulating and then acting over ability obligations during module
solving in favor of just the `ObligationCache`. The `ObligationCache`
stays alive for the entirety of a module solving and provides a
convenient mechanism for answering obligation queries with a backed
cache.
countSegments and strSplitHelp check whether the length of the string is
strictly greater-than the length of the delimiter, skipping most of the
logic when this is not the case.
Changing the check to a greater-than-or-equal allows for the case when
the string and the delimiter are equal, giving the expected result of
["", ""].
The test ensures countSegments returns a count of two when the string
and the delimiter are equal. The expected result of Str.split in that
case is ["", ""].
