Hacker News Reader

Comment by jhasse | Hacker News Reader

Sounds wonderful! I especially can't wait for incremental compilation. I can't understand how others do any work without it.

View on HN

Since 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 or rustc itself: 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.

Is it possible for rust to optimize across crate boundaries?

Yep, it's possible to enable link time optimizations.

With LTO, yes. I always forget if #[inline] does or not.

Yes, #[inline] works across crates

#[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.

Not all about. It gives an inline hint to LLVM, making it inlined more eagerly (even within a single crate) than the default.

Are generics not inlined when appropriate even without #[inline] or LTO?

You 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.

Reply on news.ycombinator.com