Downstream dependencies of a crate are rebuilt despite the changes not being public-facing

[osiewicz]

Problem

Over at Zed we've noticed that even seemingly innocent changes to the crate that has many dependents causes us to rebuild (almost) the whole world. Adding a dbg! statement to the body of non-inlineable function, formatting code, updating a dependency to a new minor version and such still forces us to rebuild all dependants of an affected crate.
Our build graph could probably be improved by splitting out crates into smaller units, but the underlying issue is that we're rebuilding the world even when the public API of a crate did not change.
Attached is our timing file for making non-public-facing change to one of the core crates of Zed: timings.zip
What could take about 9 seconds (rebuilding project + relinking zed) takes 18 seconds instead.

Proposed Solution

There are efforts in flight to make Cargo rely less on mtime as a trigger for rebuilding the crate, but we are interested in an even stronger form of this PR where only a change to the public API of a crate should trigger a rebuild of the downstream dependants.

Notes

We have an internal prototype for one potential solution that relies on rustc emitting a hash of the public API of a crate as a part of it's "Metadata Finished" notification (Zulip Thread, rustc and cargo).

[epage]

There is a strong precedence to do this within the C++ world where they have separate "definitions" (.h) from "source" (.cpp) and a lot of effort is put into keeping as much out of "definition" files as possible, including incurring extra runtime overhead through the pimpl idiom.

This will be dependent on rustc being able to provide us a hash of the API which I expect will contain most of the risk for this.

Once we have this, generics will be an easy way for people to shoot themselves in the foot wrt rebuild time. There has been talk about the compile automatically un-inlining a non-generic section of the function. I wonder if a good first step in that direction would be a clippy lint to help people find where they could do that transformation manually to maximize the benefit they'd get from this feature.

There are efforts in flight to make Cargo rely less on #14137, but we are interested in an even stronger form of this PR where only a change to the public API of a crate should trigger a rebuild of the downstream dependants.

btw I believe these are independent. One is about how we fingerprint your source while the other is about how we fingerprint your dependencies.

[epage]

Marked this as blocked due to the need for compiler support.