For symbol heavy projects, linking is a surprising bottleneck.
Some ideas to speed up compilation by not evaluating items that are not used might pan out significantly for big crates in your dep tree (that behavior might never be stable because that would allow items with compile errors in a crate that would still let your application compile, which is against the Rust approach). The same work to do that would also allow overlapping of crate evaluation between different rustc instances called by cargo, as it would require partial evaluation of crates (to do name res only and gather the symbols needed from its deps).
Another thing is that stable rust doesn't treat macros as idempotent (because that wasn't a requirement from the start, there are crates that do dynamic IO to generate types), but if they are then incr comp can be faster by not evaluating them unnecessarily.
I know people are working on a bunch of different strategies to improve both first and incremental compile times, and I'm looking forward to the fruit of their labor.
Compile times are rarely the bottleneck for me, but that doesn't mean I won't welcome any improvements on that front.
> For symbol heavy projects, linking is a surprising bottleneck.
Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.
> Another thing is that stable rust doesn't treat macros as idempotent
This seems absolutely insane to me given how pervasive macros are in Rust (I wonder how much of incremental compilation time is just repeated serde derives?). Obviously we can't just blindly treat all macros as idempotent, but an opt-in attribute on a macros that pinky-promises that it is seems like it ought to be pretty easy to implement?
Maybe somebody's looked into it and it doesn't help much? But I've heard (unverified) rumours of the opposite.