Report I/O errors from rmeta encoding with emit_fatal

[saethlin]

#119456 reminded me that I never did systematic testing to provoke the out-of-disk ICEs so I grepped through a recent crater run (#119440 (comment)) for more out-of-disk ICEs on current master and yep there's 2 in there.

So I finally cooked up a way to provoke for these crashes. I wrote a little cdylib crate that has a #[no_mangle] pub extern "C" fn write which occasionally reports ENOSPC, and prints a backtrace when it does.

code for the dylib

// cargo add libc rand backtrace
use rand::Rng;

#[no_mangle]
pub extern "C" fn write(
    fd: libc::c_int,
    buf: *const libc::c_void,
    count: libc::size_t,
) -> libc::ssize_t {
    if fd > 2 && rand::thread_rng().gen::<u8>() == 0 {
        let mut count = 0;
        backtrace::trace(|frame| {
            backtrace::resolve_frame(frame, |symbol| {
                if let Some(name) = symbol.name() {
                    if count > 3 {
                        eprintln!("{}", name);
                    }
                }
                count += 1;
            });
            true
        });

        unsafe {
            *libc::__errno_location() = libc::ENOSPC;
        }
        return -1;
    } else {
        unsafe {
            let res =
                libc::syscall(libc::SYS_write, fd as usize, buf as usize, count as usize) as isize;
            if res < 0 {
                *libc::__errno_location() = -res as i32;
                -1
            } else {
                res
            }
        }
    }
}

Then LD_PRELOAD that dylib and repeatedly build a big project until it ICEs, such as with this:

while true; do
    cargo clean
    LD_PRELOAD=/home/ben/evil/target/release/libevil.so cargo +stage1 check 2> errors
    if grep "thread 'rustc' panicked" errors; then
        break
    fi
done

My "big project" for testing was an otherwise-empty project with cargo add axum.

Before this PR, the above procedure finds a crash in between 1 and 15 minutes. With this PR, I have not found a crash in 30 minutes, and I'll be leaving this to run overnight (starting now). (A night has now passed, no crashes were found)

I believe the problem is that even though since #117301 we correctly check FileEncoder for errors on all paths, we use emit_err, so there is a window of time between the call to emit_err and the full error reporting where rustc believes it has emitted a valid rmeta file and will permit Cargo to launch a build for a dependent crate. Changing these calls to emit_fatal closes that window.

I think there are a number of other cases where emit_err has been used instead of the more-correct emit_fatal such as

rust/compiler/rustc_codegen_ssa/src/back/write.rs

Line 542 in e51e98d

sess.dcx().emit_err(errors::CopyPath::new(from, path, e));

but unlike rmeta encoding I am not aware of those cases of those causing problems.

r? @WaffleLapkin

[Nilstrieb]

We generally try to avoid fatal errors when possible, but here it looks very reasonable.
I'm not waffle and you asked for it but r=me if that works for you too

[saethlin]

I've been sending the out-of-disk PRs to Waffle because I keep getting good reviews back, so in this case thank you for taking a look, but I will wait for Waffle until the tree opens (I have no idea when that would be, but any kind of rush in these circumstances seems silly).

[WaffleLapkin]

Looks good to me too, r=WaffleLapkin,Nilstrieb once the tree feels better.

[WaffleLapkin]

I think you can drop the ; here, but it does not matter. (I prefer using expressions instead of blocks where possible, but yeah, not important...)

[saethlin]

I was actually thinking about this as I made the change

[WaffleLapkin]

Marking as S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. , since this awaits neither an action from the author or the reviewer

[Nilstrieb]

Hm, it's S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. for someone to approve it, and then it will be S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. . I see no reason to wait for approving until the tree is open, it can sit in the bors queue just fine.

[saethlin]

@bors r=WaffleLapkin,Nilstrieb rollup

[bors]

📌 Commit 94c43cc has been approved by WaffleLapkin,Nilstrieb

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.