This job isn't quite finished because it caused me to discover bugs
related to reading `ByVal(Undef)` when a `ByValPair` is expected, e.g.
for a fat pointer. This wasn't a problem with the `None` of
`Option<Value>`, but I realized an equivalent bug existed even then,
since you could transmute a `u64` like `ByVal(Bytes(42))` to a fat
pointer type on 32-bit targets.
Likewise, you could transmute a fat pointer to `u64` and get panics
related to expecting `ByVal` but finding `ByValPair`, so the problem
goes both ways.
This is step 1 of a refactoring to fix#95. The `Undefined` variant is
so far unused and the old `bits` and `relocation` fields are emulated
with two new temporary methods. There should be no functional change due
to this commit.
This takes the `AllocId` out of PrimValKind, replacing it with a
`relocation` field on `PrimVal`, which is closer to an earlier design
for `PrimVal` I discussed with @eddyb.
This commit prepares the code for removing the `PrimValKind` from
`PrimVal` and making them more pure bitbags. The only code dealing with
`PrimValKind` will be code making decisions like "what kind of operation
do I need to do on these bits", like operators and casting. Transmutes
of `PrimVal`s will become true no-ops, not even adjusting a `kind`
field.
This commit also removes my horrible `value_to_primval` hack that made
an allocation for every `ByVal` passed in, so it could use `read_value`
to get a `PrimVal` with the right kind. Now I just compute the
`PrimValKind` from the `Ty` and re-tag the `PrimVal`.
The code got slightly messier in some areas here, but I think a _lot_ of
code will simplify in obvious ways once I remove the `kind` field from
`PrimVal`.
Gosh, if my commit messages aren't turning into essays these days.
