Remap the exec root out of build script rustflags

[cpcwood]

Fixes issue: #4201

Build scripts that invoke rustc themselves bake the exec root into their output, because cargo_build_script does not include --remap-path-prefix in the CARGO_ENCODED_RUSTFLAGS it passes to them.

rustix's build.rs feature probe pipes source to rustc on stdin, so the working directory is the only path input rustc has, and it folds that into the --emit=metadata output written to $OUT_DIR. That is a declared build-script output, hashed into the cache key of every dependent crate, so the same source built at two different absolute paths produces different cache keys for the whole dependent chain.

construct_arguments() already applies --remap-path-prefix to every rustc invocation the ruleset constructs, "For determinism to help with build distribution and such". Build scripts reach rustc through CARGO_ENCODED_RUSTFLAGS rather than construct_arguments(), so they never inherited it. rustdoc is the only other exception and is documented as one.

Reproduction, with a Bazel-free minimal check and a four-workspace Bazel proof: https://github.com/cpcwood/bazel-rules-rust-rustix-cache-bust-demo

probe output
  unpatched  e27190bc...  01079d73...   differ
  patched    7e887e12...  7e887e12...   identical

Rustc actions re-executed at a second path
  unpatched  3   (rustix, //:mylib, //:myapp)
  patched    0

Verified on aarch64-darwin and ubuntu-latest. Hash values are platform-specific.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[UebelAndre]

Thanks! I had jut one question 😄

[UebelAndre]

Is mapping pwd to . correct? Won't this be the CARGO_MANIFEST_DIR which is not going to be correct outside of this action? Shouldn't there be some other mapping that the build script determines based on the OUT_DIR path location relative to the execroot for the action?

[cpcwood]

Hey, thanks for taking a look.

From my understanding --remap-path-prefix should only be changing what rustc writes into its own output, so it doesn't participate in the token substitution that makes build script output portable between actions.

${pwd} is resolved to the exec root on the way in, before the script runs, and the .env/.depenv files are built only from cargo:-prefixed lines on the script's stdout, which this shouldn't touch.

The thing being fixed is that OUT_DIR is a TreeArtifact hashed into every downstream rustc cache key. rustix's feature probe writes a --emit=metadata file in there and only reads the exit code, but rustc folds its working directory into the metadata hash, so the file's bytes differ between checkouts and re-key everything downstream. It forwards CARGO_ENCODED_RUSTFLAGS to that rustc, which is how the remap reaches it.

re: deriving the prefix from OUT_DIR - I'm unsure that'd work, OUT_DIR and the script's cwd are siblings rather than nested:

<exec_root>/bazel-out/<cfg>/bin/<pkg>/<name>.out_dir/
<exec_root>/bazel-out/<cfg>/bin/<pkg>/<name>.cargo_runfiles/<ws>/

The path that actually leaks is the working directory, and an OUT_DIR-derived prefix diverges from it at that last segment. The exec root is their only common ancestor, and since --remap-path-prefix matches on prefix it covers both. . is the same value rustc.bzl uses for non-build-script compiles.

While looking at this I realised there's another alternative if you'd prefer to avoid touching rustflags. remove_nondeterministic_out_dir_files already targets this class of issue, so adding rustix_test_can_compile to out_dir_volatile_file_basenames should fix this specific crate. I went with the remap because it'll cover any build script that forwards rustflags to rustc rather than needing an entry per crate, but happy to do that version instead if you want.