$CARGO passed to external subcommands can point to the wrong cargo if already set

[Alexendoo]

Problem

Observed in rust-lang/rust-clippy#14045, if cargo +nightly clippy is ran by a process with CARGO pointing to the stable cargo then nightly clippy-driver will be ran by stable cargo

In this case that resulted in a confusing warning

Steps

1. Put the following into your PATH as cargo-foo

   #!/usr/bin/env bash
   
   echo "$CARGO"

2. With stable cargo use cargo run on

   use std::process::Command;
   
   fn main() {
       Command::new("cargo")
           .args(["+nightly", "foo"])
           .status()
           .unwrap();
   }

3. The output will be .../.rustup/toolchains/stable-.../bin/cargo

Possible Solution(s)

Looks to be due to #11285, perhaps there could be an exception for when the current exe really is cargo

Notes

No response

Version

cargo 1.84.0 (66221abde 2024-11-19)

[weihanglo]

perhaps there could be an exception for when the current exe really is cargo

How to achieve that? I mean isn't it be like a revert of #11285?

[weihanglo]

Feel like one remote cause is the cargo-clippy is, while "official", still an external command, so need to rely on $CARGO.

[Alexendoo]

How to achieve that? I mean isn't it be like a revert of #11285?

Looking at just #10119 Cargo the binary could set a flag that disables the forwarding, that would keep #11285 working for commands that use Cargo as a library

For #10113 though I'm not sure

[smoelius]

If one invokes cargo +nightly <anything>, it's pretty clear one wants to run the cargo proxy because of the +nightly.

Are there cases where one would want the cargo proxy to preserve the CARGO environment variable? I'm wondering if the proxy should clear it.

If I'm reading #10119 right, that issue is about using Cargo as a library. So I don't think clearing the CARGO environment variable in the proxy would impact that issue's fix.