Rustc does not cleanup incomplete output files that are being outputed by rustc,
when rustc is interrupted by a catchable signal such as SIGTERM.

This does not match the behavior of gcc and clang,
where incomplete generated output files are always removed when the program exits or signal received.

This behavior is not friendly to developer, where interrupt the build of project is not an uncommon thing.
This also causes many not easy to reproduce issues, especially when Rust incremental build is enabled,
such as:

• error: failed to build archive failed to map object file: memory map must have a non-zero length #142858

This is also not good for incremental compilation that an invalid output may be considered to be up-to-date by GNU Make.

How to reproduce

Write code which is fast to compile, but output file is large. Name it as main.rs

I test the reproduce in CentOS7 and WSL2 with ubuntu 22.04

fn main() {
    // Generate a large static string at runtime
    let large_string = "A".repeat(1_000_000_000);
    println!("{}", &large_string[..10]);
}

Compile the file and immediately send SIGTERM to rustc before compilation done

 rm -f main; rustc main.rs & sleep 0.2; pkill -f rustc; ls -l

You may need to adjust the time of sleep, or try several times

It is possible that an incomplete output of main with size of 0 is generated with several .rcgu.o files

Existing implementation in other compiler

LLVM has a class llvm::ToolOutputFile that is used to generate compiler output files.
When this class is constructed, the filename is registered in a global list.
When the program exits or signal occurs, all files in the list are removed.
llvm::ToolOutputFile has a keep method to remove the file from the list.
The file is also removed if dtor of llvm::ToolOutputFile is called without calling keep() method before

Meta

rustc --version --verbose:

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5