You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
reg-vm: support struct/list/option-typed Map and Set keys
The register VM only accepted Bool/Int/String map keys (VmMapKey was a
three-variant enum), so a `derives(Eq, Hash)` struct/sum used as a `Map` key or
`Set` element - which the compiled backend keys on directly - failed at runtime
with "reg VM Map key does not support ...". That was a real VM/compiled
capability divergence (surfaced by the example-corpus differential on
uop_interning.rss).
Make VmMapKey wrap any hashable VmValue:
- equality reuses VmValue's existing structural PartialEq;
- Hash is a matching recursive projection (hash_vm_value) so equal keys hash
equal - covering scalars, String/Bytes/Char/Unit, the structural
List/Deque/Option containers, and struct/variant fields, with Managed
unwrapped transparently (consistent with Eq) and +-0.0 normalized.
map_key_from_value now accepts the full hashable shape and rejects only the
genuinely unhashable values (Float/Map/Json/Closure) with the same clean error;
vm_value_from_map_key (used by Map.keys/Set.to_list) just clones the stored
value, so keys round-trip exactly with no struct reconstruction.
Keys remain Rc-shared rather than deep-copied: Map.insert/Set.insert declare
retains(key), so the move checker forbids mutating a key while it is in a map,
which is why the (now interior-mutable) VmMapKey is sound - documented at the
scoped clippy::mutable_key_type allows.
Tests: add backends_agree_on_struct_keyed_collections (struct key with nested
List/Option: dedup, lookup, Map.keys round-trip, Set membership - VM == JIT ==
compiled) and drop the now-unneeded uop_interning skip from the example sweep.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
0 commit comments