fix: run the Android llvm-ar probe in the caller's environment

[MohammedAlkindi]

The clang_android follow-up from #1866. Related: #1859.

This is stacked on #1866 and contains its two commits. Only the last one, fix: run the Android llvm-ar probe in the caller's environment, is new here. The diff will shrink to that once #1866 lands, so this is best read after it.

What broke

The Android branch of get_base_archiver_variant works out whether the NDK ships llvm-ar under that name by running llvm-ar --version, and it built that probe with a bare Command::new:

name = format!("llvm-{tool}").into();
match Command::new(&name).arg("--version").status() {

A bare name resolves through the ambient PATH, not the one Build::env set up. So a caller that points PATH at its own toolchain gets the question answered about a different toolchain, and cc falls back to the target-prefixed name.

This is the third site of the same root cause as #1859, after family detection and is_flag_supported. It is also the one that made clang_android unable to run on my machine: the test puts llvm-ar on PATH through Build::env, the probe never saw it, and the fallback arm-linux-androideabi-ar is not there either, so cc's error path exited the process and took the whole test binary with it.

error occurred in cc-rs: failed to find tool "arm-linux-androideabi-ar": program not found

Green on CI because the runners have something the probe can find in the ambient PATH.

The change

The probe goes through set_ar_detection_env, so it inherits Build::env and gets its own recording class rather than consuming an out{i} slot. That is the third class you and I discussed on #1866, and it is the reason this is a separate PR: it widens the design from two classes to three.

ProbeKind::ArDetection maps to CC_SHIM_OUT_FILES_FOR_AR_DETECTION, and Test gains collect_ar_detection_probes and get_ar_detection_probes alongside the other two.

I did not touch the fallback logic itself, only which environment the probe asks the question in.

Verified

Windows 11, x86_64-pc-windows-msvc, rustc 1.97.1.

Before, on the unmodified branch, clang_android did not fail, it aborted the process, which is why the rest of that binary never reported. After:

tests/test.rs   59 passed, 0 failed, 0 ignored

That is the whole binary green in one run for the first time here. Previously 58 of 59 passed when run one test per process, with clang_android killing the shared run.

Everything else, on this branch: every other test binary green, doc-tests 28 passed, cargo clippy --workspace --all-targets -- -D warnings clean, cargo fmt --all --check clean, and MSRV check -p cc on 1.65.0 clean.

The new assertion is test.get_ar_detection_probes(0).must_have("--version"), which fails on unmodified source because the probe never reaches the shim and no recording exists.

One thing worth your call

The probe still runs --version and inherits stdio, so under the shim it is a real process spawn per Android build. That was already true, and I left it alone rather than widening the PR, but if you would rather it were quieted or cached, say so and I will fold it in.

LLM usage, per the Rust policy: this change was developed with AI assistance (Claude). Adding this retroactively, since it should have been disclosed when the PR was opened.

[NobodyXu]

Thanks LGTM, can be merged after the other one

[MohammedAlkindi]

Superseded by #1868, which is this same commit rebased onto main now that #1866 has landed. This branch went conflicted the moment #1866 squash-merged, exactly as flagged, and updating it in place would have needed a force-push that my setup gates on a human, so a fresh branch was the clean route to a mergeable version.

#1868 is one commit instead of three and is green: tests/test.rs 59 passed in a single run, doc-tests 28, clippy -D warnings clean, fmt clean, MSRV 1.65.0 clean. Closing this one to keep the queue honest.