winch: implement ref.null, ref.is_null, ref.func, and typed select

[r-near]

Implements the core reference type instructions for Winch (funcref only):

• ref.null: pushes a null funcref (pointer-sized zero)
• ref.is_null: compares a ref to zero, produces i32 0/1
• ref.func: calls the existing ref_func builtin to get a funcref for a function index
• typed select: delegates to the existing untyped select implementation

Non-func heap types (externref, etc.) bail with an unsupported error, consistent with how table_get, table_set, and other table ops already handle them.

Relates to #8088, #9924.

[Copilot]

Pull request overview

Adds initial support for core WebAssembly reference-type operators (funcref-only) in Winch, enabling compilation of modules that use ref.null, ref.is_null, ref.func, and typed select, while rejecting unsupported heap types in line with existing table-op behavior.

Changes:

• Implement ref.null, ref.is_null, and ref.func visitor lowering (funcref-only; other heap types error out).
• Add support for typed select by delegating to the existing select lowering.
• Extend the “supported ops” list so these operators are no longer treated as unimplemented.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Subscribe to Label Action

cc @saulecabrera

Details

This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

• saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[cfallin]

This looks reasonable overall to me -- thanks!

A few testing requests:

• It doesn't look like ref.func's return value is actually tested with a call; could you add a test case that does a table.set then a call_indirect to make use of it?
• It would be great to have disas tests (tests/disas/winch/) for all of these operators as well.

[r-near]

Thanks for the quick review @cfallin! Added the tests here: 43d2950 (this PR)

[cfallin]

Looks reasonable to me -- thanks!

[cfallin]

@r-near there's a CI test failure (see status from the merge queue attempt) -- perhaps a test is running that shouldn't yet with the current implementation status. Could you take a look?

[cfallin]

Actually I believe @fitzgen added this wasmtime::gc test hostcall recently -- Nick, could you verify this is added at the correct place in this case? Thanks!