Implement wasm proc-macros using wasmi by bjorn3 · Pull Request #157709 · rust-lang/rust

bjorn3 · 2026-06-10T14:18:15Z

This is an alternative approach to rust-lang/all-hands-2026#73. Unlike #157590 this uses wasmi + wasm32-wasip1. The advantage of this that it allows us to unconditionally depend on support for wasm proc-macros, allowing us to use them instead of the -Zdual-proc-macro hack as well as using proc-macros in the standard library without breaking cross-compilation. And by removing the last commit this can even use wasm32-unknown-unknown to avoid depending on wasi-sdk (which currently has a bootstrap cycle with rustc and thus might not be a great dependency to have for building rustc as it makes the lives of distros harder)

Once wasmtime supports all architectures for which we support host tools, swapping wasi for wasmtime is trivial. After that at a future point we can switch to the component model to allow using wasm32-wasip2 once we deem the advantages of this to outweigh the code duplication cost for the extra proc-macro ABI, extra code for handling the crate metadata for wasm components and the hack necessary to get wit-bindgen to work within the context of libproc_macro. This PR should not make this harder, while allowing us to get (some of) the benefits of wasm proc-macros earlier.

cc @Mark-Simulacrum @alexcrichton

@Mark-Simulacrum

…=Mark-Simulacrum Fix linking for wasm with crate metadata included On wasm the crate metadata ends up in a custom section. It is not possible to refer to create symbols inside a custom section, so attempting to export it during linking will result in a linker error. This keeps the target spec flag to deny compiling rust dylibs for wasm, but may theoretically allow compiling wasm rust dylibs with a custom target spec. It will help with wasm proc-macros. And in the future we can try to flip the only-cdylib option to false on wasm. Extracted out of rust-lang#157709, but also helps with rust-lang#157590. r? @Mark-Simulacrum

@Mark-Simulacrum

…=Mark-Simulacrum Fix linking for wasm with crate metadata included On wasm the crate metadata ends up in a custom section. It is not possible to refer to create symbols inside a custom section, so attempting to export it during linking will result in a linker error. This keeps the target spec flag to deny compiling rust dylibs for wasm, but may theoretically allow compiling wasm rust dylibs with a custom target spec. It will help with wasm proc-macros. And in the future we can try to flip the only-cdylib option to false on wasm. Extracted out of rust-lang#157709, but also helps with rust-lang#157590. r? @Mark-Simulacrum

@Mark-Simulacrum

…=Mark-Simulacrum Fix linking for wasm with crate metadata included On wasm the crate metadata ends up in a custom section. It is not possible to refer to create symbols inside a custom section, so attempting to export it during linking will result in a linker error. This keeps the target spec flag to deny compiling rust dylibs for wasm, but may theoretically allow compiling wasm rust dylibs with a custom target spec. It will help with wasm proc-macros. And in the future we can try to flip the only-cdylib option to false on wasm. Extracted out of rust-lang#157709, but also helps with rust-lang#157590. r? @Mark-Simulacrum

@Mark-Simulacrum

…=Mark-Simulacrum Fix linking for wasm with crate metadata included On wasm the crate metadata ends up in a custom section. It is not possible to refer to create symbols inside a custom section, so attempting to export it during linking will result in a linker error. This keeps the target spec flag to deny compiling rust dylibs for wasm, but may theoretically allow compiling wasm rust dylibs with a custom target spec. It will help with wasm proc-macros. And in the future we can try to flip the only-cdylib option to false on wasm. Extracted out of rust-lang#157709, but also helps with rust-lang#157590. r? @Mark-Simulacrum

@Mark-Simulacrum

Rollup merge of #158242 - bjorn3:wasm_rust_dylib_metadata, r=Mark-Simulacrum Fix linking for wasm with crate metadata included On wasm the crate metadata ends up in a custom section. It is not possible to refer to create symbols inside a custom section, so attempting to export it during linking will result in a linker error. This keeps the target spec flag to deny compiling rust dylibs for wasm, but may theoretically allow compiling wasm rust dylibs with a custom target spec. It will help with wasm proc-macros. And in the future we can try to flip the only-cdylib option to false on wasm. Extracted out of #157709, but also helps with #157590. r? @Mark-Simulacrum

bjorn3 · 2026-08-12T10:38:54Z

All proc-macro tests that don't involve panicking seem to work with the exception of two proc-macro that have an auxiliary dependency, where compiletest builds it for the host rather than wasm target.

For building this currently only removes the crate type check and doesn't implement crate metadata support for wasip2 or the proc-macro ABI. And for locating wasip2 needs support for loading crate metadata. Crate metadata building and loading should work for wasip1.

This can be used by cargo to determine the target for which wasm proc-macros should be compiled.