This ensures that we use the correct specialized variable at the call
site of a function. In #2725 what happened was that a generalized
function was aliased, causing it to undergo generalization again. Then,
we lost the variable used to specialize at the call site. Instead, just
link to the partial proc being aliased directly.
There is an added benefit here, which is that we can avoid the
possibly-quadratic replacement of symbols in the generated statement.
Closes#2725
Previously we only registered record accessor closures in anonymous
contexts, where we assume they must already be specialized based on the
surrounding contexts. This is not true in general since one might bind
an accessor to a name.
Closes#2567
Closes#2535
See the referenced issue for longer discussion - here's the synopsis.
Consider this program
```
app "test" provides [ nums ] to "./platform"
alpha = { a: 1, b: 2 }
nums : List U8
nums =
[
alpha.a,
alpha.b,
]
```
Here's its IR:
```
procedure : `#UserApp.alpha` {I64, U8}
procedure = `#UserApp.alpha` ():
let `#UserApp.5` : Builtin(Int(I64)) = 1i64;
let `#UserApp.6` : Builtin(Int(U8)) = 2i64;
let `#UserApp.4` : Struct([Builtin(Int(I64)), Builtin(Int(U8))]) = Struct {`#UserApp.5`, `#UserApp.6`};
ret `#UserApp.4`;
procedure : `#UserApp.nums` List U8
procedure = `#UserApp.nums` ():
let `#UserApp.7` : Struct([Builtin(Int(I64)), Builtin(Int(U8))]) = CallByName `#UserApp.alpha`;
let `#UserApp.1` : Builtin(Int(U8)) = StructAtIndex 1 `#UserApp.7`;
let `#UserApp.3` : Struct([Builtin(Int(I64)), Builtin(Int(U8))]) = CallByName `#UserApp.alpha`;
let `#UserApp.2` : Builtin(Int(U8)) = StructAtIndex 1 `#UserApp.3`;
let `#UserApp.0` : Builtin(List(Builtin(Int(U8)))) = Array [`#UserApp.1`, `#UserApp.2`];
ret `#UserApp.0`;
```
What's happening is that we need to specialize `alpha` twice - once for the
type of a narrowed to a U8, another time for the type of b narrowed to a U8.
We do the specialization for alpha.b first - record fields are sorted by
layout, so we generate a record of type {i64, u8}. But then we go to
specialize alpha.a, but this has the same layout - {i64, u8} - so we reuse
the existing one! So (at least for records), we need to include record field
order associated with the sorted layout fields, so that we don't reuse
monomorphizations like this incorrectly!
Previously we would pass the annotation down as the
type-to-be-monomorphized for, but that would just mean the annotation
would unify with itself. We instead want to use the variable the thunk
is being used as to be the one unified with the thunk's annotation.
Closes#2445Closes#2446
