wasi-http proxy components don't conform to their world as of nightly-2025-12-10

[dgohman-fastly]

This minimal repro repository contains a program to be built with --target=wasm32-wasip2. It uses a build.rs script to select the proxy adapter, intending to conform to the wasi:http/proxy world.

With Rust nightly-2025-12-09 and earlier, the compiled component conforms to the wasi:http/proxy world.

With Rust nightly-2025-12-10 and later, the compiled component contains imports not in the wasi:http/proxy world.

$ wasm-tools component wit target/wasm32-wasip2/debug/main.wasm  | grep 'import.*terminal'
  import wasi:cli/terminal-input@0.2.4;
  import wasi:cli/terminal-output@0.2.4;
  import wasi:cli/terminal-stdin@0.2.4;
  import wasi:cli/terminal-stdout@0.2.4;
  import wasi:cli/terminal-stderr@0.2.4;

These imports are not present in the wasi_snapshot_preview1.proxy.wasm adapter that's used.

Meta

The specific compiler versions are:

Works as expected with:
$ rustc +nightly-2025-12-09 --version
rustc 1.94.0-nightly (37aa213 2025-12-08)

Unexpected imports with:
$ rustc +nightly-2025-12-10 --version
rustc 1.94.0-nightly (c61a3a4 2025-12-09)

From a quick scan of the commits in that range, #147572 seems most likely to be relevant. @alexcrichton

[alexcrichton]

#147572 is definitely the cause here yeah, although what to do about it to me is a bit unclear. The reason this worked before is that the output of LLVM imported wasi_snapshot_preview1 symbols which then got different behavior depending on flags to the linker. After #147572, however, everything is using WASIp2 symbols which the linker does not support redirecting to different behavior for. To me various options here are:

• Revert this change. If this is done, however, I would like to have a clear path to relanding it, which I don't currently know of.
• Wait for component-model-level optional imports, at which point these'll all get switched to optional imports.
• Update the wasi:http/proxy world with these interfaces to reflect the reality that they're required.

Or... something else? Unsure.

If others end up finding this issue and are using the wasmtime CLI the -Scli argument should get the component working again. Not a long-term solution, but a possible workaround.