Previously we would construct the shapes of unions used in the pattern
tree for exhaustiveness checking using the type of the branch patterns,
rather than the type of the condition variable. Clearly we want to
always use the condition variable, otherwise some branches will be
seen as exhaustive, when they are not!
To do this, we now index into the condition variable while refying the
patterns to build the tree for exhaustiveness checking.
Closes#4068
We have this idea of "rigid optional" fields to annotate record fields
that must necessarily be optional. That avoids the admission of programs
we cannot faithfully compile, like
```
f : {a: Str, b ? U64}
f = {a: "b", b: 1}
```
We want to lose the rigidity restriction when a generalized symbol is
used as at a specialized site; for example it should be possible to call
`f : {x ? Str} -> {}` with both `{}` and `{x : Str}`, neither of which
have a rigidly optional field unless they were to be annotated.
Prior to this commit we would loosen the rigidity restriction upon
specialization of a generalized type at a use site. However, what we
really want to do is apply the loosening during calculation of
generalization. The reason is that otherwise, we must make types that
would be ground (like `{x ? Str} -> {}`) generalized just for the sake
of the optional field annotation. But since the rigidity constraint is
irrelevant after an annotated body has been checked, we can loosen the
rigidity restriction then, which conveniently happens to coincide with
the generalization calculation.
Closes#3955
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.
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.
