Add repro-check tool for verifying reproducible Rust builds

[windsunil]

This patch introduces a new host tool called repro-check that helps verify whether Rust compiler builds are reproducible.

Summary:
-> Builds the stage-2 Rust toolchain (or a full distribution) twice in separate workspaces.
-> Compares the resulting sysroots byte-for-byte using SHA-256.
-> Generates a detailed HTML report highlighting mismatches and ignored files.
-> Writes a deterministic bootstrap.toml for each build to ensure consistent settings.
-> Supports parallel hashing via Rayon.
-> Accepts standard options such as:
--jobs – Number of parallel jobs
--exclude-pattern – Ignore files matching a pattern
--path-delta – Adds extra directory levels to second build for path-sensitivity testing
--full-dist – Build full distribution instead of stage 2
--clean – Start from a clean workspace
--skip-copy – Reuse existing workspace without copying source
--verbose – Print detailed logging

Included components:
-> src/tools/repro-check/ – Tool source code (main.rs, build.rs, compare.rs, fs_utils.rs, config.rs)
-> Integration tests for hash computation, mismatch detection, ignored patterns, and case-insensitive handling.
-> Updates to Cargo.toml and Cargo.lock to include repro-check dependencies.
-> Bootstrap and builder updates to register the new tool.

References:
Tracking issues: #139793, #134589, #144669

Usage:

Build the tool

./x.py build src/tools/repro-check

Run (stage2 only, host target)

./build/x86_64-unknown-linux-gnu/stage1-tools-bin/repro-check

Full distribution with custom options

./build/x86_64-unknown-linux-gnu/stage1-tools-bin/repro-check
--jobs 16
--exclude-pattern .so
--path-delta 10
--html-output my-report.html

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Kobzol]

r? kobzol

Thank you for working on this! I will take a look, and also nominate this for the next t-infra meeting.

[Kobzol]

We discussed this at our infra meeting, and we're unsure of who should maintain this tool, and if we have enough interest in fixing repro bugs, if they appear. Continuing the discussion on compiler stream on Zulip.

We think that it might make sense to merge such a tool and keep it in for some time, to see if it finds any issues, and if we have someone to actually go and try to fix such issues. And then we can evaluate later if its maintenance costs offset the gains.

[windsunil]

We discussed this at our infra meeting, and we're unsure of who should maintain this tool, and if we have enough interest in fixing repro bugs, if they appear. Continuing the discussion on compiler stream on Zulip.

We think that it might make sense to merge such a tool and keep it in for some time, to see if it finds any issues, and if we have someone to actually go and try to fix such issues. And then we can evaluate later if its maintenance costs offset the gains.

---

Thanks for the discussion and for considering this.

I agree with treating repro-check as an experimental tool initially. The goal from my side is to help surface reproducibility issues and provide a concrete way to compare builds. While I’m not a deep Rust compiler expert, I’m happy to help with using the tool for investigation, analyzing CI reports, narrowing down differences, and collaborating with the relevant teams when issues are found.

I’m also fine with revisiting or adjusting the tool if the maintenance cost turns out to be too high. I’ll follow the discussion on the compiler stream on Zulip as well. Thanks again!