Rustdoc output slightly nondeterministic #24473
Comments
sfackler
added
the
T-rustdoc
|
May be as easy as changing |
ghost
added
the
E-easy
|
Using @jakub-'s solution barring catastrophe |
…xcrichton This ensures that later when generating HTML, the JSON will be sorted aswell. We now have a more deterministic build of sidebar-items.js Closes rust-lang#24473
…xcrichton This ensures that later when generating HTML, the JSON will be sorted aswell. We now have a more deterministic build of sidebar-items.js Closes rust-lang#24473
|
This still appears to be present in other contexts than the one that was fixed: sfackler/rust-openssl@bca2a36 |
sfackler
removed
the
E-easy
rustdoc: use btree map for where clauses to get more reproducible output. Fixes: rust-lang#32555 I've looked at the other uses of HashMap in rustdoc, and they seem ok to (i.e. they use `iter()` and related only for constructing a new map, or when the output goes into independent files). Not sure what the cause of rust-lang#24473 is, it shouldn't be where clauses, but maybe it was also fixed inbetween since May 2015.
rustdoc: use btree map for where clauses to get more reproducible output. Fixes: rust-lang#32555 I've looked at the other uses of HashMap in rustdoc, and they seem ok to (i.e. they use `iter()` and related only for constructing a new map, or when the output goes into independent files). Not sure what the cause of rust-lang#24473 is, it shouldn't be where clauses, but maybe it was also fixed inbetween since May 2015.
Steps towards reproducible builds cc #34902 Running `make dist` twice will result in a rustc tarball where only `librustc_back.so`, `librustc_llvm.so` and `librustc_trans.so` differ. Building `libstd` and `libcore` twice with the same compiler and flags produces identical artifacts. The third commit should close #24473
Steps towards reproducible builds cc #34902 Running `make dist` twice will result in a rustc tarball where only `librustc_back.so`, `librustc_llvm.so` and `librustc_trans.so` differ. Building `libstd` and `libcore` twice with the same compiler and flags produces identical artifacts. The third commit should close #24473
|
PR #35984 has been first included in the 1.13 release. Still, in 1.14 there is some non-determinism left, inside the search index. See this diffoscope output. I think the issue is that the search index gets sorted by the order in which rustdoc finishes the build of the crates. We'd need a better mechanism in order to get determinism. Maybe a final pass to sort by the crate name? |
|
Hmm, as of 1.14 it didn't sort, but since PR #38105 which was first included in 1.15, it does sort. So this sub-issue can be viewed as fixed. |
frewsxcv
added
the
T-dev-tools
|
Yep. I couldn't reproduce the issue on master (786ccc3). The only concern I have is that tests.reproducible-builds.org still shows |
|
Nevermind. Seems searchindex.js is still having an issue. https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/diffoscope-results/rustc.html |
|
searchindex.js is generated by mdbook, not rustdoc. I think we can close this issue. |
|
@kzys Issue from 1.28.0 release already solved in rust-lang/mdBook#692 |
|
Awesome! I am not sure how Debian gets docs, but maybe we need to upgrade mdbook here? rust/src/tools/rustbook/Cargo.toml Line 11 in b7c6e8f |
jonas-schievink
added
the
A-reproducibility
There's a bit of nondeterminism in rustdoc output across runs even when the source doesn't change: sfackler/rust-openssl@1cb83ff I'm guessing it's due to randomized HashMap iteration order.
It'd be nice to switch to a non keyed Hasher or maybe just TreeMaps in rustdoc to avoid "phantom" documentation updates.
The text was updated successfully, but these errors were encountered: