Closed q82419 closed 4 years ago
The semantics of asserts is such that it only requires the string to match the prefix of the actual error message, and this has been used a bit inconsistently across tests. Most implementations don't care about the concrete string anyway, but happy to accept patches if you feel strongly that this should be cleaned up. :)
I found that there are some incompatible failure strings.
out of bounds
In tests such ascore/table_grow.wast
, the failure strings when a trap occurs areout of bounds table access
. In tests such ascore/memory_grow.wast
, the failure strings when a trap occurs areout of bounds memory access
. But the failure strings in some files such ascore/data.wast
,core/elem.wast
,core/linking.wast
, etc. are onlyout of bounds
. Is that true to fix them asout of bounds table access
andout of bounds memory access
?unknown
s In old tests, the failure strings are onlyunknown memory
,unknown table
, etc. inassert_invalid
tests. But incore/table_init.wast
,core/memory_init.wast
,core/memory_fill.wast
,core/memory_copy.wast
, andcore/ref_func.wast
, the index added:unknown memory 0
,unknown table 0
,unknown element segment 4
, etc. Furthermore, incore/memory_init.wast
, there are 2 types of strings:unknown data segment
andunknown data segment 1
. Can it have a general failure string format, contains or without the unknown instance index?undefined element
In tests such ascore/call_indirect.wast
andcore/func_ptrs.wast
, the failure string when trap occurs incall_indirect
instruction isundefined element
. But incore/linking.wast
, the string isundefined
. Are them the same failure and the string should be fixed toundefined element
?Thanks.