WebAssembly for procedural macros #876
Labels
major-change
A proposal to make a major change to rustc
T-compiler
Add this label so rfcbot knows to poll the compiler team
Uh oh!
There was an error while loading. Please reload this page.
Proposal
Create an experimental implementation of not-yet-proposed language feature to use WebAssembly for procedural macros. This would involve compile procedural macro crates to
wasm32-unknown-unknown
(or potentiallywasm32-wasip2
) and then executing them to perform macro expansion with a WebAssembly runtime driven by rustc.In principle, using WebAssembly would provide many significant benefits. A working implementation would enable these benefits, as well as costs, to be validated.
Major components
Internal
wasm_procmacros
language featurewasm32-unknown-unknown
within rustcUser-facing
-Zproc_macro_execution_strategy
to includewasm
-Zwasm_runtime=<PATH>|<NAME>
to specify the name of a wasm runtime, i.e.wasmtime
or the path to an executableRationale
The current model of proc macro expansion—using dynamically-linked libraries—creates build reproducibility and security hazards for the Rust ecosystem. WebAssembly is one mechanism for improving our posture that shows a lot of promise.
Reproducibility
Because procedural macros can access the entire system, it's easy to introduce entropy into the build. Environment variables, the system clock, and other external sources of input mean that it's very difficult to guarantee a reproducible build.
Build speeds
As WebAssembly is inherently cross-platform, proc macros could be compiled once and re-used in each target within a build. This would reduce the number of times a proc macro is compiled from n targets to 1.
The situation even improves further when one considers that transitive dependencies of proc macros would no longer need to be fetched and compiled for each target.
Implementation notes
Guidance is welcome to advise on the most appropriate implementation strategy.
This MCP would touch at least the following parts of the rustc codebase:
compiler/rustc_builtin_macros
: [TODO: check if any special treatment is needed here]compiler/rustc_codegen_ssa
/compiler/rustc_codegen_llvm
: Logic added to compile proc macros towasm32-unknown-unknown
, irrespective of the build's actual target platform.compiler/rustc_expand
: Logic added to proc macro expansion to use wasm when the feature is enabledcompiler/rustc_macros/proc_macro_server.rs
: create aWasm
type that mirrors the existingRustc
compiler/rustc_metadata
: Add functionality to load a crates compiled as wasm, analogous to the native_libs and creader modules.compiler/rustc_session
: Support wasm as possible choice ofproc_macro_execution_strategy
; addwasm_runtime
option-library/proc_macro
: [TODO: check if changes are needed]Interactions with
wasm_c_abi
compiler feature may complicate matters. For example, consider this comment withinlibrary/proc_macro/src/bridge/mod.rs
:Mentors or Reviewers
[None currently]
Related issues
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
The text was updated successfully, but these errors were encountered: