GRGrayShade·Dec 11, 2019
> Essentially, compile only what has changed, re-use compiled forms of everything that hasn't.
That's what incremental compiling does, and it has been enabled for a while. Unfortunately, it doesn't help on fresh builds.
> Essentially, pre-compiled dependencies will be sourced and plugged in to a Rust project.
There are two aspects here. The more recent one, which you are thinking of, is building and shipping procedural macros as WASM binaries. Procedural macros are very powerful, but they take a token stream as input to allow for future changes to the language. Because of this, basically every macro uses a Rust parser crate called syn. Since it's a fully-fledged parser, syn takes a while to compile (30 seconds or so, certainly not minutes), which many people find annoying, and it gets worse if you end up using different versions of syn fo
Read the rest
r different proc macro crates. The plan here is to build the proc macros (including syn) somewhere on the Rust infrastructure and ship the binaries to the users. The sandboxing story is somewhat complicated: proc macros and build scripts can legitimately read or download files, or produce non-deterministic output in other ways. A WASM macro would not be able to do this, so the whole thing would be opt-in. It also provides no benefit for crates that don't use procedural macros. See https://github.com/dtolnay/watt for more details.
The other possible avenue is MIR-only rlibs. When you compile a dependency, you get machine code (with the exception of generic code). It might be possible to compile crates to MIR (again, on the Rust infrastructure) and only do the final codegen on the user's computer. But that's still complex, and not necessarily much faster. See https://github.com/rust-lang/rust/issues/38913.