abrown opened Issue #1681:
When troubleshooting WAST test failures, it is difficult to determine what is different between the expected V128 pattern (e.g.
[0, 1, 2...]) and the giant integer contained inVal::V128. I attempted a solution to this in #1650 that changed the internal Rust representation of V128 values fromu128to[u8; 16]. Though this worked and all tests passed, it was only a partial solution: with[u8; 16]it was visually easier to troubleshoot which lanes were incorrect but it didn't exactly match the output of, e.g., an i32x4 vector.To fully resolve this, we need to either manually implement
DebugforValor add aValDisplaystruct to:
- print V128 values as hexadecimal (and do the same with the expected side in
wast.rs)- or use the variants of
V128Patternto parse and display theVal::V128to match theV128Patternlanes/types.
abrown closed Issue #1681:
When troubleshooting WAST test failures, it is difficult to determine what is different between the expected V128 pattern (e.g.
[0, 1, 2...]) and the giant integer contained inVal::V128. I attempted a solution to this in #1650 that changed the internal Rust representation of V128 values fromu128to[u8; 16]. Though this worked and all tests passed, it was only a partial solution: with[u8; 16]it was visually easier to troubleshoot which lanes were incorrect but it didn't exactly match the output of, e.g., an i32x4 vector.To fully resolve this, we need to either manually implement
DebugforValor add aValDisplaystruct to:
- print V128 values as hexadecimal (and do the same with the expected side in
wast.rs)- or use the variants of
V128Patternto parse and display theVal::V128to match theV128Patternlanes/types.
Last updated: Dec 13 2025 at 19:03 UTC