RDR has not seen significant progress ever since the MCP has been accepted due to my limited availability. I do plan to pick it up back again around RustWeek. There's also now a small group of people interested in helping out with this MCP's implementation that includes: - @davidbarsky - @P1n3appl3 - @capickett - @fasterthanlime We met on April 7th - we are all gonna attend RustWeek as well. #### Current obstacle - ICEs I managed to minimize the crash I saw when trying to use RDR in a non-toy manner; adding items to a crate may cause ICE (or - even worse - miscompilations) in dependents. The reproduction case is available [on my GH](https://github.com/osiewicz/rdr-crash-1). We'll get back to this particular problem in a bit - but first, a digression! #### Starting small My goal is for RDR to be usable and helpful in a Nightly build. We would love to dogfood RDR over at Zed (even with Nightly build), but frankly my prototype is quite useless (outside of maybe gauging impact of RDR on your project). Can we somehow reformulate the problem to make it easier to solve? Which properties of RDR that were initially sketched out complicate our life the most? During the MCP process, great focus was placed on diagnostics: we need to figure out how to update diagnostics in crates that do not get rebuilt due to RDR. Well. What if we just did not apply RDR to crates with any cached diagnostics? If there's at least one warning or error in your crate, we'll always rebuild it - even if none of your dependencies have changed it's API hash. This would leave backtraces as the only "dubious" space we'd have to check. Still, if the goal is for RDR to be usable, I think having up-to-date diagnostics is a great perk. We can iterate from that. #### Back to the original problem I think we should ensure DefId stability for local items reachable from the outside of a crate. That way .rmeta with same public API hash should be interchangeable. One way to tackle this is to postprocess the assigned DefIds and bucket them into (public, non-public) partitions. I am not sure how feasible that is, since we'd have to rely on `reachability_set` query for that, and it is computed after we obtain HIR of a crate.