`is_flag_supported` ignores `Build::env` overrides; `gnu_debug_fp`/`gnu_debug_fp_auto` fail on Windows hosts without a system `cc` (since #1845)

[MohammedAlkindi]

Environment: Windows 11, rustup stable-x86_64-pc-windows-gnu, mingw-w64 gcc 16.2 on PATH as gcc.exe — no cc.exe (where cc finds nothing), no MSVC installed. I'd expect this to be a common shape for Windows contributors using rustup plus a mingw toolchain.

Symptom: on a fresh clone of main, cargo test --test test fails:

thread 'gnu_debug_fp' panicked at tests\test.rs:119:17:
didn't find "-mno-omit-leaf-frame-pointer" in ["-O2", "-ffunction-sections", "-fdata-sections",
"-fPIC", "-g", "-gdwarf-4", "-fno-omit-frame-pointer", "-m64", "-o",
"...\\db3b6bfb95261072-foo.o", "-c", "foo.c"]

gnu_debug_fp_auto fails the same way. This started when #1845 made -mno-omit-leaf-frame-pointer conditional on is_flag_supported. CI stays green, but for a reason that I think is itself a bug — see below.

Mechanism (traced with CC_ENABLE_DEBUG_OUTPUT=1):

The test framework only exposes the shim directory through Build::env:

// tests/support/mod.rs
.env("PATH", self.path())   // shim dir prepended

Build::env overrides are applied to the Tool's spawn environment at the end of try_get_compiler ("Do this last, to allow overwriting the other values above"), and the main compile honors them. But is_flag_supported_inner (src/lib.rs:1488) constructs a fresh Build for the probe and copies compiler / opt_level / debug / cpp / cuda / … — everything except self.env. So the probe resolves and spawns cc against the real process environment:

running: "cc" "-E" "...\detect_compiler_family.c"
cargo:warning=Compiler family detection failed due to error: ToolNotFound: failed to find tool "cc": program not found
running: "cc" "-O2" ... "-g" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" ... "-c" "foo.c"   <-- flag missing
exit code: 0

Consequences:

• On a host with a system cc (every current CI runner), the probe silently uses that compiler rather than the shim — the test passes, but it is testing the host compiler's flag support.
• On a host without one (this machine), the probe fails, is_flag_supported comes back false via .unwrap_or(false), the flag is silently dropped, and the test fails.
• Outside the test suite, any user who configures a Build with .env(...) (say a PATH or CC override) gets flag probes that ignore those overrides — and since do not emit -mno-omit-leaf-frame-pointer if unsupported #1845 that can silently change which flags are emitted.

Why this isn't a PR yet: the small fix — copying self.env into the probe's Build —

             if let Some(host) = &self.host {
                 cfg.host(host);
             }
+            // Pass along the custom env vars the user specified with
+            // `Build::env`, so that the probe resolves and spawns the
+            // compiler in the same environment as the real invocation.
+            for (key, val) in &self.env {
+                cfg.env(key, val);
+            }
             cfg.try_get_compiler()?

— does make the probe hit the shim, and the flag is then emitted (verified here: the main compile gains -mno-omit-leaf-frame-pointer). But the shim then records the probe invocation (the -c cwd fallback in cc-shim.rs anticipates exactly this), which shifts the out{N} indices, and gnu_debug_fp fails differently: cmd(0) now matches the probe's arguments instead of the main compile's. cc-shim.rs also documents that family detection "must keep failing", so the framework currently depends on probes and detection not seeing the shim. That seems like a design decision rather than a drive-by patch: should probes see the shim (then recordings/indices and family detection need explicit handling), should the framework pin probe results for tests, or should these tests avoid asserting probed flags? Happy to send a PR for whichever direction you prefer.

Related: #851 (env overrides dropped on the get_compiler path — same family of problem), #1632 (probe mechanics), #1844 / #1845 (the change that exposed this).

[NobodyXu]

Thank you for reporting!

For the out{n}, maybe we can have another env to control its the ns to be used, i.e. CC_SHIM_OUT_FILES="out1 out0"

[MohammedAlkindi]

CC_SHIM_OUT_FILES would work, and I like that it makes each test say explicitly which recordings it means instead of depending on invocation order. Two details probably worth deciding before the PR:

1. Who computes the indices. If each test sets CC_SHIM_OUT_FILES itself, every probing test has to know how many probe invocations precede the main compile — and that count changes whenever a flag moves between is_flag_supported and unconditional emission. A variant with the same shape but less coupling: have the shim tag what it saw (e.g. write out{n}.probe when the invocation looks like a probe — -E on detect_compiler_family.c, or a compile of the flag-check source), and have cmd(n) skip probe-tagged recordings unless a test opts in. Existing tests then keep passing untouched as probe counts drift, and a future gnu_debug_fp can assert the probe invocation too.

2. Family detection. cc-shim.rs documents that detection "must keep failing". Once the probe Build carries self.env (the underlying fix), detection also resolves through the shim, and its outcome becomes whatever the shim does with -E detect_compiler_family.c — so the shim needs an explicit stance (answer as a fixed family, or keep detection env-isolated) for is_flag_supported's clang/gnu branching to stay deterministic in tests.

Happy to send the PR in whichever form you prefer — CC_SHIM_OUT_FILES exactly as proposed, or the tagged-recordings variant — together with the self.env copy into the probe Build.

[NobodyXu]

Yes having dedicated indices for family detection/is-flag-supported is indeed necessary

What I say we can do, is to have a special env for is_flag_supported and family detection - we used to have a hidden set_env, so we could theoretically has another hidden function like this, i.e. CC_SHIM_OUT_FILES=out999,out2000,...

Or, if we don't want a hidden function, we could have an env var CC_SHIM_OUT_FILES_FOR_FAMILY_DETECTION and CC_SHIM_OUT_FILES_FOR_FLAG_SUPPORT_CHECK; before running the cmd, instead of just copying over self.envs blindly, we take special handling and rename these env variables.

[MohammedAlkindi]

The two explicit env vars read better to me than another hidden function: the recording contract stays visible in the test that uses it, and there's no private API surface to keep alive. A hidden setter has the same coupling problem the bare indices had — it just moves it out of sight. The rename approach also has a nice property: the special vars never collide with a user's real build env, because the shim only ever sees the one list cc chose for that invocation class.

One edge worth pinning down before it's written: what a probing invocation does when its dedicated var is absent (an older test, or a probe the test didn't anticipate). Falling back to the plain CC_SHIM_OUT_FILES order would silently reintroduce the ordering coupling; not recording at all keeps the classes separate — a test that didn't declare interest in probe output shouldn't be counting it.

[NobodyXu]

One edge worth pinning down before it's written: what a probing invocation does when its dedicated var is absent (an older test, or a probe the test didn't anticipate). Falling back to the plain CC_SHIM_OUT_FILES order would silently reintroduce the ordering coupling; not recording at all keeps the classes separate — a test that didn't declare interest in probe output shouldn't be counting it.

Yeah I think not recording at all is the best action we can take

[MohammedAlkindi]

Verified fixed on main. Same box and same command both times, with no cc, gcc, clang or cl on PATH, which is the condition in the title.

At 1301078, gnu_debug_fp and gnu_debug_fp_auto both pass. At caf7609, the commit before #1866 landed, both fail:

didn't find "-mno-omit-leaf-frame-pointer" in ["-O2", "-ffunction-sections", "-fdata-sections",
"-fPIC", "-g", "-gdwarf-4", "-fno-omit-frame-pointer", "-m64", "-o", ".../foo.o", "-c", "foo.c"]

Command: cargo test --test test gnu_debug_fp, exit 101 before and 0 after.

set_probe_env and the three CC_SHIM_OUT_FILES_FOR_* variables went in with #1866 and #1868 and match what we settled above, including recording nothing when a probe's dedicated variable is absent. I do not see anything outstanding here.

[NobodyXu]

cc v1.4.4 has released

I will close this issue, if you've found it's still not fixed feel free to reopen it or open another issue.