Open letheed opened 8 years ago
We have just observed the same (non-deterministic JSON ordering) during reproducible rebuilds in Debian. In general, it would be a good idea to make the serialization deterministic.
This should be filed in the rust-lang/cargo repo.
@sfackler actually I did that in the first place but I was told to open a new one here. The original bug report can be found here
Yes I think this is likely related to the nondeterminism of running multiple processes at once and I think that rustdoc can probably add more safeguards/sorting rather than Cargo handling this (unless I'm misunderstanding)
Triage: is anyone still seeing this issue? Any way of reproducing it more easily?
I noticed that the documentation generated by
cargo doc
was not exactly the same depending on if I rancargo test
orcargo build
first.Running:
search-index.js
: the indexes for my two targets (a [lib] and a [[bin]]) are swapped. The two lines are identical but since they're swapped git detects a file modification when my script copies the doc over to the gh-pages branch, and the file is commited for nothing.fn.solve_from.html
(which is a public function in the [[bin]] crate): the trait bound on the parametric type does not link over to its own documentation in the [lib] crate any more:The first point is not that big of a problem but the second one is clearly a bug.
As suggested by @alexcrichton, using the
--jobs 1
flag on bothcargo doc
andcargo build/test
solves the problem by making the process deterministic, at the expense of compile/docgen time obviously.