Previously, if the lambda set passed to a HOLL contained any function
that captured, we would assume that the specialization of the HOLL we
should make for each function in the lambda set that we dispatch to
should capture.
This is not right. Instead, we should specialize for each lambda in the
set passed to the HOLL. The present patch enforces that, making sure
that for each lambda in the set, we compute the exact proc layout needed
to call the lambda, based on the captures of the specific lambda in the
set, rather than looking at the set entirely.
Previously, we determined whether a closure argument should be added to
the proc layout of a compiled function by checking whether the lambda
set was material at all. But, the extension for a single function should
be added if and only if the function itself captures.
Some of the head-constructor tests we generate can be supersets of other tests.
Edges must be ordered so that more general tests always happen after their
specialized variants.
For example, patterns
[1, ..] -> ...
[2, 1, ..] -> ...
may generate the edges
ListLen(>=1) -> <rest>
ListLen(>=2) -> <rest>
but evaluated in exactly this order, the second edge is never reachable.
The necessary ordering is
ListLen(>=2) -> <rest>
ListLen(>=1) -> <rest>
Closes#4732
And provide expectation subs when expectations should be compiled. This
will be useful for getting the specialized type of an expect lookup when
it's available.
This actually isn't needed, because the backends must lookup the layout
from the environment anyway. So it's enough to lookup the symbol and
find its layout, there is no need to additionally store it.
When compiling a pattern match like
```
[] -> ..
[_] -> ..
[_, ..] -> ..
```
to a decision tree, we must make sure that the last test (len >= 1)
does not touch the branch reached by the second test (len == 1). It is
enough to ban (len >=) tests from ever touching exact-sized list
patterns, because a spread test (len >=) can never reach an exact-sized
test.
On the other hand, an exact-sized test can reach a spread pattern,
because in
```
[_, _] -> ..
[..] -> ..
```
the last branch generates tests for patterns `[]` and `[_]`, and we would
like those patterns to be covered by the spread test (len >= 0)!
Closes#4685
