chore(bazel): bump rules_rust to bazelbuild/rules_rust@5f04c8c1

[claude]

Requested by Nicolas Mattia · Slack thread

What

Upgrades the rules_rust Bazel module pin in bazel/rust.MODULE.bazel from the 0.71.3 release tarball to a codeload.github.com snapshot of the latest commit on bazelbuild/rules_rust's default branch, matching the archive_override + codeload pattern already used for other Bazel modules in this repo (e.g. rules_motoko, rules_foreign_cc in the root MODULE.bazel).

• Before: https://github.com/bazelbuild/rules_rust/releases/download/0.71.3/rules_rust-0.71.3.tar.gz (release 0.71.3)
• After: https://codeload.github.com/bazelbuild/rules_rust/tar.gz/5f04c8c14c2ffacfe10ad14e55298be21454be04 (commit 5f04c8c1, latest on main as of 2026-07-24: "Add cargo_build_script.use_cc_toolchain (refactor(nns): Make Governance environment parameters compatible with timer usages #4161)")
• strip_prefix updated to rules_rust-5f04c8c14c2ffacfe10ad14e55298be21454be04 and the integrity hash recomputed for the new tarball (sha256 of the codeload archive fetched from an unrestricted network, converted to the sha256-<base64> SRI form to match the field format already used by this override).

Patches

• Removed bazel/rules_rust_dep_env.patch: this worked around DEP_* cross-crate env vars being redacted to an unresolved ${out_dir} token in build-script dep-env files (e.g. libssh2-sys failing to find zlib.h via libz-sys's DEP_Z_INCLUDE). This is now fixed upstream by Fix unresolved ${out_dir} token in dep env files bazelbuild/rules_rust#4124 ("Fix unresolved ${out_dir} token in dep env files"), which is included as of the new pinned commit — confirmed by diffing cargo/private/cargo_build_script_runner/lib.rs at the new commit against the patch: the upstream code now uses redact_exec_root instead of full redact_paths in outputs_to_dep_env, matching the patch's intent, and even includes the same libssh2-sys/libz-sys regression test. The patch no longer applies (git apply --check fails cleanly against the new file content) and its reference was removed from rust.MODULE.bazel.
• Kept bazel/rules_rust_strip_level.patch unchanged: it configures per-compilation-mode strip levels, which the native rust.toolchain tag's flat strip_level string_dict still cannot express (Cannot specify per-target strip_level in MODULE.bazel bazelbuild/rules_rust#3730 is still open upstream — traced the full call chain through rust/extensions.bzl → rust/private/repositories.bzl → rust/private/toolchain.bzl's _rust_toolchain_impl, which still requires a per-compilation-mode dict at the rule level that the bzlmod extension tag cannot produce). Verified the patch still applies cleanly (git apply --check, 3-line offset, no fuzz) against rust/extensions.bzl fetched at the new target commit.
• No other patches reference rules_rust in this repo.
• No MODULE.bazel.lock file exists in this repo, so there is nothing to regenerate there.

Validation

What I was able to run in my sandbox:

• buildifier -mode=check bazel/rust.MODULE.bazel — clean, no reformatting needed (exit 0).
• buildifier -lint=warn bazel/rust.MODULE.bazel — only pre-existing warnings unrelated to this change (canonical-repository @@ warnings elsewhere in the file, far from the diff).
• Fetched the exact files both patches touch at the exact target commit (rust/extensions.bzl, cargo/private/cargo_build_script_runner/lib.rs) and ran git apply --check against them locally, as described above.
• The sha256/integrity value was computed from a real fetch of the codeload tarball for the target commit, done outside my sandbox (my sandbox's network egress blocks codeload.github.com for any repo other than dfinity/ic), then converted to SRI format and round-tripped back to hex to confirm the conversion was correct.

What I could not run in my sandbox, and why:

• bazel build / bazel test / bazel fetch for this change specifically: my sandbox's network egress blocks (a) codeload.github.com tarball fetches for non-dfinity repos, (b) the ghcr.io/pkg-containers.githubusercontent.com blob storage needed to pull the pinned ic-dev dev-container image, and (c) releases.bazel.build binary downloads needed to get a matching Bazel 9.2.0 outside the container. All three are independent, hard network-egress restrictions in that environment, not fixable from within it.

Given that, this PR's actual build/test signal will need to come from CI once it runs here. Please treat a green CI run (in particular anything that exercises @rules_rust toolchains/cargo_build_script) as the real confirmation that the new pin, hash, and patch set are correct before merging this out of draft.

Testing

• CI build/test is green (this is the validation this sandbox could not produce locally — see above)
• Confirm no other in-repo patches or docs reference bazel/rules_rust_dep_env.patch

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.