Unrolled build for #155991

Rollup merge of #155991 - lqd:in-flight-query-profiling, r=bjorn3

Catch unwinds from the global ctxt callback to complete queries profiling data in more cases

The driver/compiler interface provides multiple callbacks, and we sometimes catch unwinds to flush diagnostics, ensure ICEs appear, and so on even when fatal errors occur.

When these panics happen, we don't `finish` the `TyCtxt`, and there's a fixme about that. Unfortunately this is where we also allocate the self-profile strings: query events for example start as virtual and are turned into real strings by this finalization process; they are _invalid_ without this step. When fatal errors happen, the in-flight query name will be `<unknown>`, event counts will be inaccurate, etc.

This PR catches panics from another of these callbacks, where the `TyCtxt` is available, to allow for the self-profiling data to be computed before continuing the unwinding process as before. `finish` does more things, that I don't want to introduce here.

I remember seeing this discussed in GH issues in the past, but can't find any open ones now. It may also have been only mentioned while trying to profile existing slowness issues. I stumbled upon this again recently when looking into `tests/ui/try-trait/deep-try-chain-issue-153583.rs`, where the slowest query is `<unknown>`.

```
> rm *.mm_profdata ; rustc +nightly -Zself-profile tests/ui/try-trait/deep-try-chain-issue-153583.rs ; summarize summarize *.mm_profdata | head -n 5

error[E0277]: the `?` operator can only be applied to values that implement `Try`
 --> tests/ui/try-trait/deep-try-chain-issue-153583.rs:6:5
  |
6 |     0?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????...
  |     ^^ the `?` operator cannot be applied to type `{integer}`
  |
  = help: the nightly-only, unstable trait `Try` is not implemented for `{integer}`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0277`.
+------------------------------------------------------+-----------+-----------------+----------+------------+
| Item                                                 | Self time | % of total time | Time     | Item count |
+------------------------------------------------------+-----------+-----------------+----------+------------+
| <unknown>                                            | 1.55s     | 99.416          | 3.21s    | 15230      |
+------------------------------------------------------+-----------+-----------------+----------+------------+
```

This PR fixes that case at least. In general, it should fix the invalid profiling records for fatal errors happening while a query is running.

```
+------------------------------------------------------+-----------+-----------------+----------+------------+
| Item                                                 | Self time | % of total time | Time     | Item count |
+------------------------------------------------------+-----------+-----------------+----------+------------+
| typeck_root                                          | 5.04s     | 95.588          | 5.08s    | 1          |
+------------------------------------------------------+-----------+-----------------+----------+------------+
```

r? @bjorn3

Author: rust-timer

compiler/rustc_interface/src/passes.rs

@@ -1016,9 +1016,24 @@ pub fn create_and_enter_global_ctxt<T, F: for<'tcx> FnOnce(TyCtxt<'tcx>) -> T>(
             feed.crate_for_resolver(tcx.arena.alloc(Steal::new((krate, pre_configured_attrs))));
             feed.output_filenames(Arc::new(outputs));
 
-            let res = f(tcx);
-            // FIXME maybe run finish even when a fatal error occurred? or at least
-            // tcx.alloc_self_profile_query_strings()?
+            // There are two paths out of `f`.
+            // - Normal exit.
+            // - Panic, e.g. triggered by `abort_if_errors` or a fatal error.
+            //
+            // If a panic occurs, we still need to wind down the self-profiler to correctly record
+            // the query events that are still in flight. Otherwise, they will be invalid and will
+            // show up as "<unknown>" in the profiling data.
+            let res = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| f(tcx)));
+            let res = match res {
+                Ok(res) => res,
+                Err(err) => {
+                    tcx.alloc_self_profile_query_strings();
+
+                    // Resume unwinding if a panic happened.
+                    std::panic::resume_unwind(err);
+                }
+            };
+
             tcx.finish();
             res
         },