Currently things like `1 / 200` lead to a miscompilation because we type
`200` (and as a result, both `1` and the division result) as a ranged
number with width >= U8. During mono that forces the number to become an
`I64` because our logic was that a ranged number can only become a float
if it's at least as wide as an I8. But this is incorrect; as long as the
type is wrapped in `Frac` constructor and it's a ranged number (and not
a ranged int), it should become a fractional type.
```
» 1 / 200
0.005 : Float *
```
Closes#4047
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
Closes#3224
This should also fix a number of other issues often observed when a
lambda is never actually called, but we fail to codegen because it has
an empty lambda set.
