Description
Meta: I'm going to expand upon the description of this issue over time and hopefully compile a tasklist of concrete issues.
Seemingly innocuous and irrelevant modifications to a crate (like the reordering, addition or removal of unrelated items) may alter rustdoc's output compared to a previous build (which often manifests itself in a change in the order of “the things we are interested in”1).
I presume that this can only affect things for which rustdoc needs to look at the crate metadata (e.g., cross-crate re-exports and synthetic impls (blanket and auto-trait impls)).
I'm not in the know regarding the root cause since I don't know much about the internals of the crate metadata format (layout, serialization, deserialization). I suspect it might have something to do with the use of FxHash{Set,Map}s during or after deserialization but that could be flat out wrong.
Maybe it isn't even related to rmeta but only to FxHash{Set,Map}, I really don't know. I just know that these kinds of “fluctuations” are stable under recompilation (of the input crate(s) and of rustdoc itself) and under reruns (of rustdoc) and only unstable under what I have inferred to be “crate metadata changes”. So while rustdoc's output is apparently deterministic, it's not necessarily fully predictable.
Concrete examples and elaborations can be found below:
- rustdoc: various cross-crate reexport fixes #103885 (comment)
- rustdoc: fix & clean up handling of cross-crate higher-ranked parameters #116388
- Use diagnostic namespace in stdlib #119216 (comment)
Footnotes
-
Ideally, the order wouldn't change at all and take the order either from the source code or from some predictable or known ordering (alphabetical, etc.) ↩