component model async: wrong string encoding in `task.return` intrinsic

[BigOrangeQWQ]

Test Case

composed.wasm
runner-c.wasm
test-c.wasm

Steps to Reproduce

• Use the WIT interface:

package my:test;

interface i {
  ping: async func(x: future<string>, y: string) -> future<string>;
  pong: async func(x: future<string>) -> string;
}

world test {
  export i;
}

world runner {
  import i;
}

• Compile two components: runner-c.wasm (UTF-8) and test-c.wasm (UTF-16). Both of these components are built from wit-bindgen ping-pong test
• Compose these components into a single composed.wasm using wasm-tools component compose.
• Run composed.wasm using Wasmtime.

Expected Results

The async function should complete successfully, and the task.return operation should not panic.

Actual Results

Error: failed to run main module `composed.wasm`

Caused by:
    0: failed to invoke `run` function
    1: error while executing at wasm backtrace:
           0:  0x2ca9f - test-c.core.wasm!exports_test_async_ping_return
           1:  0x2bf63 - test-c.core.wasm!exports_test_async_ping_callback
           2:  0x2ca51 - test-c.core.wasm!__wasm_export_exports_test_async_ping_callback
       note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
    2: invalid `task.return` signature and/or options for current task

Versions and Environment

Wasmtime version or commit: wasmtime 38.0.0 (024db5b4e 2025-09-08)

Operating system: MacOS 15.6.1

Architecture: arm64

Extra Info

The async lift of the function's signature contains UTF-16 encoding information. If this encoding is modified to UTF-8, the program will continue to run.

[alexcrichton]

Thanks for the report! I've transferred this to the wasm-tools repository since after taking a look I believe the bug lies here. Specifically what's happening is that the host isn't panicking but generating a trap. The trap generated by the host is correct and the guest binary is wrong here. The task.return intrinsic used by the "ping" function has the wrong string encoding on it, so the wasm-tools component new step in this repository I believe isn't correctly applying the string encoding argument to that intrinsic.