At the time we introduced presence constraints for tag unions, I added a
"destruct_position" variable so that we didn't change the typechecking
semantics for everything all at once, and because I wasn't totally sure
what I was doing was correct. But now we're more confident in this
approach, and every pattern is by definition a destructuring, so there
is no need for this flag.
Also should fix some potential bugs we didn't notice before with presence
constraints in closure variables, though I can't find a good test to
reproduce this, since closure variables are hidden from the user.
std::fs::canonicalize adds a special windows prefix ?, zig erroneously (ziglang/zig#1509) does not allow ? in windows paths, dunce correctly removes this ? prefix
Flags should not contain whitespaces since the value is split on them
Update compiler/build/src/link.rs
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
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!
