Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Occasional non-reproducibility when building librls and libcargo #68608

Closed
jgalenson opened this issue Jan 28, 2020 · 2 comments
Closed

Occasional non-reproducibility when building librls and libcargo #68608

jgalenson opened this issue Jan 28, 2020 · 2 comments
Labels
A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. S-needs-repro Status: This issue has no reproduction and needs a reproduction to make progress. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jgalenson
Copy link

Occasionally (perhaps 1/3 of the time, so it's not that rare) when doing multiple builds with extended = true (and hence building tools including rls and cargo), I get different libcargo.rlib and librls.rlib files.

During a normal build, libcargo gets built once (reproducibly for me), but on these bad builds it gets built twice. The command line is slightly different the second time, as it has ,artifacts appended to its --json argument (due to this code). This difference gets propagated to librls, which depends on libcargo.

I believe this is due to rustc's bootstrap compiler invoking cargo separately for each tool. If the cargo build finishes early enough, the rls build can use its result. But if it does not, the rls build seems to fire off its own compile, which causes the above issue.

Note that this is a part of #34902.

@jonas-schievink jonas-schievink added A-reproducibility Area: Reproducible / deterministic builds T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 28, 2020
@Mark-Simulacrum
Copy link
Member

cc @alexcrichton @ehuss -- potentially another case like #68149? Haven't looked into this in detail though.

@JohnTitor JohnTitor added the C-bug Category: This is a bug. label Feb 2, 2020
@Mark-Simulacrum
Copy link
Member

I'm going to go ahead and close this as without reproduction instructions it'll be iffy to reproduce, and RLS itself is gone now anyway. (We've also shuffled the workspaces so I think there's less intentional sharing regardless).

@jieyouxu jieyouxu added S-needs-repro Status: This issue has no reproduction and needs a reproduction to make progress. A-rls labels Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. S-needs-repro Status: This issue has no reproduction and needs a reproduction to make progress. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants