abrown commented on issue #6705:
Here's where the errors start: https://github.com/bytecodealliance/wasmtime/actions/runs/5490314463/jobs/10005600074#step:16:3205.
alexcrichton commented on issue #6705:
I think these failures are related to
wasmparser
and its validation, so the test suite submodule probably will need to get updated in the wasm-tools repository before it's updated here.
alexcrichton commented on issue #6705:
With https://github.com/WebAssembly/testsuite/pull/68, https://github.com/bytecodealliance/wasm-tools/pull/1126, and publishing wasm-tools this should be good to go.
abrown commented on issue #6705:
Ok, rebased on top of #6739.
alexcrichton commented on issue #6705:
Oh can you also try re-updating the submodule its latest? I think that will surface a single error in
tests/spec_testsuite/elem.wast:690
which I think is something we need to implement, but otherwise the other failures I think are fixed by updating the test suite
alexcrichton commented on issue #6705:
Ok I think those are legitimate failures where we accidentally don't support
global.get
in table element segment offset initializers.
TethysSvensson commented on issue #6705:
It seems like
global.get
has been a constant expression at least since 2017 (WebAssembly/spec#445). However it was not usable inside element segments until the reference types proposal landed in 2021 (WebAssembly/spec#1287). This made funcrefs/externrefs available as globals, and thusglobal.get
became usable in element segments.Unfortunately the interaction between this proposal and element segments was initially missed and a test was not added for it until earlier this year in WebAssembly/spec#1640. I think most wasm parsers missed this detail. For instance wabt only added support for this today in WebAssembly/wabt#2288.
Last updated: Dec 23 2024 at 12:05 UTC