Closure captures can be transient, but previously, we did not handle
that correctly. For example, in
```
x = ""
inner = \{} -> x
outer = \{} -> inner {}
```
`outer` captures `inner`, but `inner` captures `x`, and in the body of
`outer`, we would not construct the closure data for `inner` correctly
before calling it.
There are a couple ways around this.
1. Update mono to do something when we are passed the captured
environment of a closure, rather than attempting to construct a
call-by-name's captured environment before callign it.
2. Fix-up closures during canonicalization to remove captured closures
that themselves capture, and replace them with their captures.
This patch does (2), since (1) is much more involved and is not likely
to bring a lot of wins. In general I think it's reasonable to expect
captured environments, even if transient, to be fairly shallow, so I
don't think this will produce very large closure environments.
Closes#2894
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.
This enables you to write something like
```
A := U8
List.map [1, 2, 3] @A
```
which will be compiled as if it was `List.map [1, 2, 3] \x -> @A x`.
Closes#3499
