Everytime, when a Cargo project is first built, all dependencies have to be compiled from source to an internal format. Then subsequent builds don't need dependencies built again; aka. incremental compilation.
What if Rust supported its own bytecode format, which retains all the language semantics, allowing Cargo to skip building dependencies by sharing bytecode to crates.io? For example, different from LLVM bitcode or WebAssembly, the Rust's bytecode format would store conditional compilation attributes (
env!(...), features, macros (including their inner
include_bytes! etc.), module items... everything from Rust. Then the program build phase can import and export bytecode.
So supporting Rust's proper bytecode would speed up the first build phase. I'm not sure how much that'd benefit, because in some ways the bytecode has to be verified like the sources... but there are many differences... like, it'd avoid parsing the Rust syntax, would strip indent characters and more... (maybe would retain documentation comments for use by IDEs and RustDoc).
If a crate has a build.rs, its build.rs should execute before its bytecode is reused. The bytecode must be able to reuse build.rs artifacts... so
include! and several other macros have to stay unresolved at the bytecode level.
When macros clearly don't rely on build.rs artifacts, they can be resolved at the bytecode level...
This doesn't prevent compilation exactly
Dependency crates are still incrementally compiled, except their source isn't parsed. Only build.rs is parsed, maybe.
Importing and exporting a proper bytecode has an advantage. It allows manipulating Rust programs in other ways, including allowing it to be embedded in other software without low-level WebAssembly or LLVM bitcode.
The main point of this idea about preventing source recompilation isn't clear whether it's worthy; it might improve parsing speed if the bytecode format is more compact and easier to parse than the Rust syntax.