Cargo run silently passes arguments to target binary if user accidentally messes up +version order

[orlp]

Problem

I recently was (for a short while) tricked into believing my program was stuck in an infinite loop. I had ran the command

cargo run +nightly --release

It took me a while to realize that what I had written resulted in target/debug/foo.exe +nightly --release being ran, instead of running in release mode with the nightly compiler. I feel this is quite error prone, and that it's undesirable this happens entirely silently.

Proposed Solution

I propose that we display a warning when the first argument that cargo run interprets as an argument for the binary to run starts with a +. The warning can be silenced by prefixing the start of your binary argument list with -- (which you probably already should be doing anyway). So cargo run -- +nightly --release would not result in a warning, as it indicates the user really intended this behavior.

It could also simply be an error rather than a warning to start the first argument with a +, which would've probably been the better behavior from the start, but this could break existing scripts.

Notes

No response

[weihanglo]

Ah! Seems like a common pitfall people often bump into (a similar one: #10362). We'd love to provide a way to avoid that.

Unfortunately, +toolchain is provided by a cargo proxy, which is controlled by rustup. Cargo itself knows nothing about toolchains. Emitting warnings when detecting + in arguments of the binary seems a little risky to me, because existing scripts might not expect to receive any output, though it should be rare I guess. At this time, I cannot think of a better way without breaking stuff 😞

Anyway, thanks for your report and proposal!

[orlp]

To be maximally conservative about breaking scripts you could only output the warning if stderr is a tty.

[ehuss]

This was accidentally closed by a typo.

[orlp]

This was accidentally closed by a typo.

And here I got excited when I saw the "fixed by commit" email... 😢