-
-
Notifications
You must be signed in to change notification settings - Fork 15k
nondeterministic ordering in rmeta section #113584
Copy link
Copy link
Closed
Labels
A-metadataArea: Crate metadataArea: Crate metadataA-reproducibilityArea: Reproducible / deterministic buildsArea: Reproducible / deterministic buildsC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Metadata
Metadata
Assignees
Labels
A-metadataArea: Crate metadataArea: Crate metadataA-reproducibilityArea: Reproducible / deterministic buildsArea: Reproducible / deterministic buildsC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
We are running determinism checks on
rustcoutputs in our build infrastructure, basically running arustcaction twice in a row (backing up outputs from the first run) and comparing outputs. We have found that in one of our build environments (not directly accessible), this determinism check fails rather reliably on the same targets, while the exact same compilation appears deterministic in another local environment, and is thus difficult to manually reproduce.We have been able to save and retrieve difference-pairs of rlibs when the determinism check fails, and need help determining the nature of the differences. So far we have determined that the differences lie in the
rmetasection of the rlibs, but we do not understand the meaning or origin of these differences. This is where we need help. Identifying these content difference may help us create more reliably reproducible test cases to follow up with.I will attach one pair of such rlibs shortly, with some more details.