[adwn]

I always wonder: If the proc macros were executed JIT-like with the Cranelift backend instead of compiling them with the LLVM backend, wouldn't that drastically reduce build times of proc-macro-using code? The Rust compiler spends most of its time in LLVM, if I recall correctly.

[cormacrelf]

The most promising proposal so far is to compile proc macros to WASM. Then you precompile them to a single cross-platform WASM binary, publish those to crates.io alongside the source code, and then execute them in a sandbox. You wouldn’t see much benefit until all your chosen proc macros were available in this form, but after a while this would be great, basically no downsides. In fact you can publish proc macros this way today, IIRC with some caveats about compiler versions (?), but it’s manual and a proof of concept only so nobody has done it.

The only thing missing was effort into the idea to make it the default and able to be supported long term. You need a stable WASM ABI that won’t change across rustc versions and for someone to add a runtime to rustc.

Dtolnay (the author of the Watt concept) recently put out a message looking for help putting together an RFC. https://twitter.com/davidtolnay/status/1574913813400330241

[__jem]

The brightest minds in the Rust community are investigating! https://github.com/dtolnay/watt

[vegerot]

The article breaks down how much time is spent by each part of the compiler (borrow checking, LLVM, macro expansion, etc.) check it out!

[strager]

I have heard talk of compiling proc macro crates with different rustc flags than other code. But I didn't go down this rabbit hole.

[epage]

Someone recently looked into doing this by default. The problem was the results varied depending on how often your "host dependencies" (proc macro, build.rs) were shared with your "target dependencies" (`dependencies`, `dev-dependencies`). When there was a lot of sharing, it hurt, but otherwise it sped up build times.