Closed mkarup closed 1 week ago
Thanks a lot ! It looks like Binaryen is finally implementing the spec exactly. All these instructions are either things that have been renamed in the GC proposal or old custom instructions from Binaryen. :) I'll make a PR to fix these issues.
@mkarup, this should have been fixed by #3. Feel free to re-open if you find another issue. Thanks again for the report!
(Also, please note that there's no more .wast
files, I renamed all of them to .wat
, it was an old misnaming...)
Some of the Wasm text format instructions used when emitting the
.wast
files are not part of the text format in official GC spec (and by extension, not recognized by Binaryen), meaning that the compilation fails when linking withwasm-merge
.There may be more issues, but here are a few that I spotted in
wasm/wast.ml
,wasm/runtime_binaryen.wast
andwasm/imports_binaryen.wast
(I'm not sure if they will actually be used in practice when emitting the wast):array.init_static
is not a recognized instruction (maybearray.new_fixed
instead?)ref
needs to be add in front of the alias. For example(ref.cast (ref i31) (local.get $a)))
instead of(ref.cast i31 (local.get $a)))
(or using the abbreviationi31ref
)(ref.cast (ref $Float) (local.get $a))
instead of(ref.cast $Float (local.get $a))
ref.i31
instead ofi31.new
array.len
takes a type alias argument:(array.len ...)
instead of(array.len $Array ...)
struct.new_cannon
is not a recognized instruction (maybestruct.new_default
instead?`)br_on_cast_static
is not a recognized instruction (not sure what the equivalent instruction would be)br_on_i31
is not a recognized instruction (not sure what the equivalent instruction would be)array.new_canon_fixed
is not a recognized instruction (maybearray.new_default
instead?)(register ...)
is not recognized in the module (runtime_binaryen.wast
/imports_bynaryen.wast
), I think there is a new way to link modules withwasm-merge
tuple
prefixDisclaimer: My suggested fixes may be incorrect (or there is a more elegant way)