`cargo run` "process didn't exit successfully" overwrites last line of a program that uses carriage return

[ds84182]

Problem

See title. CR can be used to continuously update a line.

Steps

fn main() {
  print!("hewwo\r");
}

Possible Solution(s)

Output a leading newline before writing out the error text.

Notes

No response

Version

cargo 1.96.0-nightly (f298b8c82 2026-02-24)
release: 1.96.0-nightly
commit-hash: f298b8c82da0cba538516b45b04a480fc501d4c0
commit-date: 2026-02-24
host: x86_64-pc-windows-msvc
libgit2: 1.9.2 (sys:0.20.4 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Home) [64-bit]

[epage]

When we run it, we call exec_replace

cargo/src/ops/cargo_run.rs

Line 128 in a07c49a

process.exec_replace()

See also https://docs.rs/cargo-util/latest/cargo_util/struct.ProcessBuilder.html#method.exec_replace

So on Linux, Cargo never sees the exit code of the program.

On Windows, we do see it. We pass it to

cargo/src/bin/cargo/commands/run.rs

Line 233 in a07c49a

fn to_run_error(gctx: &GlobalContext, err: anyhow::Error) -> CliError {

Our choices that I see

• Windows should be like Linux and not show anything by default. Maybe we show it on verbose
• Windows has enough special error codes, it justifies showing it
  • Would inserting a newline be too noisy in the common case?

[ds84182]

• Windows should be like Linux and not show anything by default. Maybe we show it on verbose

The error output is very useful on Windows since STATUS_DLL_NOT_FOUND is rather common when linking to DLLs that haven't been copied into the target folder or visible in PATH. The only other way to see this error is to run the program through Explorer or start target/<blah>/<blahblah>.exe.

In this case on Linux, the dynamic linker itself writes error while loading shared libraries: libblah.so: cannot open shared object file: No such file or directory to stderr. Same thing for Segmentation fault/Bus error/etc. with most libc's.

Also Windows error codes are named and standardized, meanwhile on Linux a process can exit with any non-zero status (exiting with a correct errno is not guaranteed).

• Would inserting a newline be too noisy in the common case?

I wouldn't consider it noisy. In the common case it would just be a blank line that separates the output from the process from cargo's output.

[epage]

@ChrisDenton any thoughts on this?

[ChrisDenton]

I definitely think printing the exit code is valuable when using cargo run. Otherwise there can be no indication that something failed. On Linux bash will helpfully print something like:

Aborted                    cargo run

But on the first-party Windows shells that doesn't happen.

Adding a new line before error output (if any) sounds fine to me.