4 ms·
Sounds wonderful! I especially can't wait for incremental compilation. I can't understand how others do any work without it.
by jhasse 11y ago
Sounds wonderful! I especially can't wait for incremental compilation. I can't understand how others do any work without it.
- steveklabnik 11y agoSince crates are the compilation boundary, and you can make projects out of multiple crates, larger Rust projects tend to be split up, even internally. Take Servo, for instance: https://github.com/servo/servo/tree/master/components https://github.com/servo/servo/tree/master/components or rustc itself: https://github.com/rust-lang/rust/tree/master/src https://github.com/rust-lang/rust/tree/master/src Each of these subdirectories (basically, a few aren't) is a crate, so you'll only be recompiling stuff in the subdirectory you're editing. Incremental compilation will still help with projects like this, of course.
- saosebastiao 11y agoIs it possible for rust to optimize across crate boundaries?
- vhbit 11y agoYep, it's possible to enable link time optimizations.
- steveklabnik 11y agoWith LTO, yes. I always forget if #[inline] does or not.
- phildawes 11y agoYes, #[inline] works across crates
- chrismorgan 11y ago#[inline] is all about cross-crate work; inside a crate, items not marked #[inline] may still be inlined by the optimiser, but it doesn’t do cross-crate inlining without #[inline] or LTO.
- dbaupp 11y agoNot all about. It gives an inline hint to LLVM, making it inlined more eagerly (even within a single crate) than the default.
- ben0x539 11y agoAre generics not inlined when appropriate even without #[inline] or LTO?
- kibwen 11y agoYou don't need the #[inline] attribute when generics are involved, because Rust already has to cross-crate-export function metadata when generics are involved because otherwise it would be impossible to monomorphize. At that point, LLVM will inline the monomorphized functions as it deems fit.