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 fromu128
to[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
Debug
forVal
or add aValDisplay
struct to:
- print V128 values as hexadecimal (and do the same with the expected side in
wast.rs
)- or use the variants of
V128Pattern
to parse and display theVal::V128
to match theV128Pattern
lanes/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 fromu128
to[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
Debug
forVal
or add aValDisplay
struct to:
- print V128 values as hexadecimal (and do the same with the expected side in
wast.rs
)- or use the variants of
V128Pattern
to parse and display theVal::V128
to match theV128Pattern
lanes/types.
Last updated: Dec 23 2024 at 12:05 UTC