Code change:
Sometimes when things go really wrong the compiler emits a ton of error messages. This can actually take a while to render them all. And since somewhat recently, hitting Ctrl-C no longer interrupts that, I get a thousand error messages displayed after Ctrl-C. I suspect this may have to do with The Ctrl-C handler does nothing at all on the first Ctrl-C unless the compiler is in the middle of const-eval. Cc
Do you have a reproducer? I have not run into this myself. The implementation should also ensure that the compiler exits promptly if you hit ctrl+c again. Does it?
if stuff keeps going on ctrl+c, sometimes suspending the process (ctrl+z) and then killing the terminal does the trick somehow :sweat_smile:
Unfortunately no, I encountered this during some rustc hacking where I ended up getting well over 1k error messages in the standard library build and that turned out to be hard to cancel. I thought I had tried that, but I am not entirely sure.
Is it possible the shell is part of the problem? If, by the time you hit ctrl-c, it's working through a large amount of output it still has buffered then it might be awhile before you see a response.
It's possible, sure -- but usually it reacts to Ctrl-C immediately even when there's tons of output.
Have you tried reverting to check if that fixes it?
No. At the time I was busy getting a PR done and now I don't have a reproducing example any more.
only checks for ctrl-c during const eval, so if no const eval runs for an extended period of time, the ctrl-c will be silently ignored. This is not the only problem with that PR. It also caused , and shows the "compilation was interrupted" error after the prompt is already drawn by bash.
is there a good way to make rustc loop endlessly without ever touching const eval? maybe via the trait solver? :thinking: it would help for debugging this.
Yeah, just take any issue (none are anyway). I can reproduce this issue with for example: nightly-2024-03-26 (before ): Exits after a single ^C nightly-2024-03-27 (after ): Requires ^C^C to exit bjorn3's analysis checks out.
cool! I wasn't sure how much of the compiler's code flowed through const-eval, is why I asked.
Another case where this is observed: IMO we should revert or at least make the signal handler run after a short timeout.
I'll post a PR that adds a timeout later today, but by all means if you feel strongly just put up a PR. The initial handler here was just through the normal PR process, there's no reason to be more cautious on reverting or modifying it.

Related discussion:
text: pub fn install_ctrlc_handler() { #[cfg(not(target_family = "wasm"))] ctrlc::set_handler(move || { <del> // Indicate that we have been signaled to stop. If we were already signaled, exit // immediately. In our interpreter loop we try to consult this value often, but if for // whatever reason we don't get to that check or the cleanup we do upon finding that // this bool has become true takes a long time, the exit here will promptly exit the // process on the second Ctrl-C. if CTRL_C_RECEIVED.swap(true, Ordering::Relaxed) { std::process::exit(1); } </del> <ins> // Indicate that we have been signaled to stop, then give the rest of the compiler a bit of // time to check CTRL_C_RECEIVED and run its own shutdown logic, but after a short amount // of time exit the process. This sleep+exit ensures that even if nobody is checking // CTRL_C_RECEIVED, the compiler exits reasonably promptly. CTRL_C_RECEIVED.store(true, Ordering::Relaxed); std::thread::sleep(Duration::from_millis(100)); std::process::exit(1); </ins> }) .expect("Unable to install ctrlc handler"); }