Skip to content

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

Open
lqd wants to merge 1 commit intorust-lang:mainfrom
lqd:in-flight-query-profiling
Open

Catch unwinds from the global ctxt callback to complete queries profiling data in more cases#155991
lqd wants to merge 1 commit intorust-lang:mainfrom
lqd:in-flight-query-profiling

Conversation

@lqd
Copy link
Copy Markdown
Member

@lqd lqd commented Apr 30, 2026

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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 30, 2026
Comment thread compiler/rustc_interface/src/passes.rs Outdated
Comment thread compiler/rustc_interface/src/passes.rs Outdated
…from queries

fatal errors currently abort the compiler process without allocating the self-profile
strings: query events aren't always correctly recorded, and will show up as <unknown>
in the data.

catching the unwinding panic allows us to finalize the self-profiling process correctly
before continuing unwinding as before.
@lqd lqd force-pushed the in-flight-query-profiling branch from 786c4da to e4eb91c Compare April 30, 2026 13:15
@bjorn3
Copy link
Copy Markdown
Member

bjorn3 commented Apr 30, 2026

@bors r+

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors Bot commented Apr 30, 2026

📌 Commit e4eb91c has been approved by bjorn3

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 30, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Apr 30, 2026
…jorn3

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
rust-bors Bot pushed a commit that referenced this pull request Apr 30, 2026
…uwer

Rollup of 13 pull requests

Successful merges:

 - #155249 (Fix: On wasm targets, call `panic_in_cleanup` if panic occurs in cleanup)
 - #155853 (Use `_mcount` as the mcount symbol name on RISC-V Linux GNU targets)
 - #155919 (simplify `ast_fragments!`)
 - #155939 (Add feature gate for view_types experiment)
 - #155974 (add `c_variadic_experimental_arch` feature)
 - #155991 (Catch unwinds from the global ctxt callback to complete queries profiling data in more cases)
 - #156003 (Pass Session to optimize_and_codegen_fat_lto)
 - #153566 (Add suggestion for E0401 on inner const items)
 - #154610 (Suggest public re-exports when a private module makes an import path inaccessible)
 - #155523 (Reorganize `tests/ui/issues/` - 02)
 - #155980 (Move `feature*` methods from `parse` mod to `errors` mod.)
 - #155987 (Make lifting infallible)
 - #155988 (tests/run-make/print-cfg: add Android target_env case)
jhpratt added a commit to jhpratt/rust that referenced this pull request May 1, 2026
…jorn3

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants