Disable Ctrl-C handling on WASM

WASM fundamentally doesn't support signals. If WASI ever gets support for notifying the guest process of a Ctrl-C that happened, this would have to be done through the guest process polling for the signal, which will require thread support in WASI too to be compatible with the api provided by the ctrlc crate.

Author: bjorn3

compiler/rustc_driver_impl/Cargo.toml

@@ -5,7 +5,6 @@ edition = "2021"
 
 [dependencies]
 # tidy-alphabetical-start
-ctrlc = "3.4.4"
 rustc_ast = { path = "../rustc_ast" }
 rustc_ast_lowering = { path = "../rustc_ast_lowering" }
 rustc_ast_passes = { path = "../rustc_ast_passes" }
@@ -66,6 +65,11 @@ features = [
  "Win32_System_Diagnostics_Debug",
 ]
 
+[target.'cfg(not(target_family = "wasm"))'.dependencies]
+# tidy-alphabetical-start
+ctrlc = "3.4.4"
+# tidy-alphabetical-end
+
 [features]
 # tidy-alphabetical-start
 llvm = ['rustc_interface/llvm']

compiler/rustc_driver_impl/src/lib.rs

@@ -1500,6 +1500,7 @@ pub fn init_logger(early_dcx: &EarlyDiagCtxt, cfg: rustc_log::LoggerConfig) {
 /// Install our usual `ctrlc` handler, which sets [`rustc_const_eval::CTRL_C_RECEIVED`].
 /// Making this handler optional lets tools can install a different handler, if they wish.
 pub fn install_ctrlc_handler() {
+ #[cfg(not(target_family = "wasm"))]
  ctrlc::set_handler(move || {
  // 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