[spec] Test subsumption in return call result types - #2211
Conversation
rossberg
left a comment
There was a problem hiding this comment.
Sorry for the churn, but on second thought, these tests belong in the respective test files for return_call and return_call_indirect (and return_call_ref, for that matter). The subtyping.wast file is meant to test the correctness of the subtyping algorithm itself (for GC types), not whether it is applied in all the right places.
Since the respective test files are not under gc/, though, it would be good to avoid the use of GC types, e.g., use (ref $functype) vs funcref instead, which should work independent of the presence of GC.
|
No worries thats actually a nicer solution 👍🏼 |
rossberg
left a comment
There was a problem hiding this comment.
Thanks! Can you also add a respective test for return_call_ref?
|
Its seems to already have these covered in slightly different examples: spec/test/core/return_call_ref.wast Line 226 in 025bcbf and spec/test/core/return_call_ref.wast Line 280 in 025bcbf |
Pick up the reference tests added to `test/core` since the 2026/07/08 update, plus one block the earlier updates missed: * `wasm-3.0/return_call` and `wasm-3.0/return_call_indirect`: the result-subtyping cases from WebAssembly/spec#2211 - a `return_call` whose callee returns `(ref null $t)` under a `funcref` result, and the `assert_invalid` for the reverse direction. * `wasm-3.0-gc/type-subtyping`: the "Invalid abstract subtyping" block from WebAssembly/spec#2116, twelve `assert_invalid` cases over the bottom heap types. It has been upstream since 2026/03 but the file was never re-synced. `return_call` and `return_call_indirect` are regenerated with wast2json (wabt 1.0.41), which reproduces the previous data byte for byte. `type-subtyping` uses `json-from-wast` of wasm-tools (1.253.0) instead, because wast2json 1.0.41 cannot parse the `(type $e (sub (array i32)))` form the file opens with. Assisted-By: Claude Opus 5 (Anthropic) Signed-off-by: YiYing He <yiying@secondstate.io>
While validating a GC module in my runtime, I found that return_call and return_call_indirect were comparing result types for exact equality instead of using result type matching. This was a left over from implementing tail call before gc, and caused a certain valid fixture to fail.
This PR adds tests for both instructions. For each instruction, I've included a valid case showing that (ref array) matches (ref eq), and an invalid case showing that the reverse direction is rejected. The cases are intentionally minimal rather than repeating the broader subsumption coverage already present.