My concern with the previous wording is that:
- Beginners will be confused by "these are always open"
- Users advanced enough to understand what that actually means won't benefit from seeing it in this warning message!
When we attempt to bind a type argument to an ability in an alias/opaque
instantiation, we create a fresh flex var to represent satisfaction of
the ability, and then unify the type argument with that flex var.
Previously, we did not register this fresh var in the appropriate rank
pool.
Usually this is not a problem; however, our generalization algorithm is
such that we skip adjusting the rank of redundant variables. Redundant
variables are those that are in the same unification tree, but are not
the root of the unification trees.
This means that if such a flex able var becomes the root of a
unification tree with the type argument, and the type argument is itself
generalized, we will have missed generalization of the argument.
The fix is simple - make sure to register the flex able var into the
appropriate rank pool.
Closes#4408
Args.roc has always been in a broken state, relying on particular
hand-holding of the compiler to operate. With recent changes to type
emplacement, Args.roc now shows off compiler bugs that cannot be papered
over and need to be addressed head-on. These are problems that I do not
think can be directly solved via eliminating type emplacement; I think
they are a combination of constraining and mono bugs, and will be
investigated separately.
For now, turn off attempts to build Args, and instead just test that
`roc check` continues to behave well.
Prior to this commit, we emplace type variables into `Index<TypeTag>`
only for translated top-level types. However, we need to be careful to
do this emplacement for nested types as well! This patch ensures we do,
but immediately emplacing the destination variable of a type when we
allocate a variable for it.
