Adjust `bug!`/`span_bug!` emission by nnethercote · Pull Request #162873 · rust-lang/rust

nnethercote · 2026-09-16T22:02:59Z

PR #161873 moved these macros from rustc_middle to rustc_span. In doing so it made some undesirable changes.

The internal emit_producing_nothing became public.
The macros now have different behaviour to function-based ICEs like dcx.bug(..) or dcx.struct_bug(..).emit().

This commit reverts those changes. This brings back Box<dyn Any> output in a few tests because the panic payload is ExplicitBug (which std doesn't know about) rather than String. That might be worth fixing again in the future, but if so, it should be done in a way that works with all aborts, not just those done via the macros.

r? @mejrs

rustbot · 2026-09-17T00:34:49Z

miri is developed in its own repository. If the Miri part of this change can be broken out, consider making this change to rust-lang/miri instead. However, if Miri needs adjusting for rustc changes, just ignore this message.

cc @rust-lang/miri

RalfJung · 2026-09-17T05:48:00Z

-broken MIR in Item(DefId) (after phase change to runtime-optimized) at bb0[1]:
-place (*(_2.0: *mut i32)) has deref as a later projection (it is only permitted as the first projection)
+thread 'rustc' ($TID) panicked at compiler/rustc_interface/src/callbacks.rs:LL:CC:
+Box<dyn Any>


This looks like a regression, the useful error got replaced by Box<dyn Any>?

View changes since the review

Ah, this is a partial revert of #161873.

This commit reverts those changes. This brings back Box output in a few tests because the panic payload is ExplicitBug (which std doesn't know about) rather than String. That might be worth fixing again in the future, but if so, it should be done in a way that works with all aborts, not just those done via the macros.

I don't know, having nice errors in some cases seems better than never having nice errors.

The thing to note is that isn't obvious from the (default, unexpanded) diff: the nice error always appears a few lines above in the actual ICE diagnostic, with a proper span. So the Box<dyn Any> replacement is just repetition.

Yeah I know that. Though this can be easy to miss when looking at the output in a terminal or copying it into an issue tracker.

We have lived with that for years so it's not the end of the world. It is just unfortunate that we just managed to fix the problem and should now re-introduce it...

I'll give some thought to a proper fix.

mejrs · 2026-09-17T10:32:06Z

The problem with panicking inside the callback is that you can't use #[track_caller] across storing the function pointer in a static, so this PR creates panic messages that first point at either callback's definition location:

example: x.py test rustc_span

#[test]
fn x() {
    let _x = Ident::new(sym::empty, DUMMY_SP);
}

Current output:

thread 'tests::x' (43212) panicked at compiler\rustc_span\src\tests.rs:5:14:
called `Ident::new` with empty symbol

Output with this PR:

thread 'tests::x' (43776) panicked at compiler\rustc_span\src\macros.rs:56:5:
compiler\rustc_span\src\tests.rs:5:14: called `Ident::new` with empty symbol

That might be worth fixing again in the future, but if so, it should be done in a way that works with all aborts, not just those done via the macros.

You could change span_bug etc to do this, then they would do the same thing.

pub fn span_bug(self, span: Span, msg: impl Into<Cow<'static, str>>) -> ! {
    let msg = msg.into();
    rustc_span::span_bug!(span, "{}", msg)
}

nnethercote · 2026-09-17T23:29:07Z

Another problem with #161873: because the macros are no longer panicking with ExplicitBug, the test ExplicitBug tests in report_ice are broken and these extra messages are printed:

error: the compiler unexpectedly panicked. This is a bug

Four of them were added to .stderr files in #161873.

These messages are not supposed to be printed for controlled bug-level aborts, because those aborts already have the full ICE message. These messages are supposed to be printed for uncontrolled "how did we get here?" panics. This whole mechanism is now broken, and ExplicitBug might as well not be present. This is bad and needs to be fixed.

It covers a case that isn't currently covered: `-Ztrack-diagnostics` in combination with a `span_bug!` ICE. Notably, the "created at" line mentions `callbacks.rs`, which is the wrong location. This will be fixed in the next commit.

PR rust-lang#161873 moved these macros from `rustc_middle` to `rustc_span`. In doing so it made some undesirable changes. - The internal `emit_producing_nothing` became public. - It gave the macros different behaviour to function-based ICEs like `dcx.bug(..)` or `dcx.struct_bug(..).emit()`. - `ExplicitBug` is not used, so `report_ice` prints an extraneous, unintended "the compiler unexpectedly panicked" message. - It broke the interaction between `span_bug!` and `-Ztrack-diagnostics`. This commit adjusts things to avoid the undesirable changes. It required moving `ExplicitBug` to `rustc_span`. Setting `diag.emitted_at` fixed the `-Ztrack-diagnostics` problem, seen in the change from `callback.rs` to `validate.rs` in `track7.stderr`. `Box<dyn Any>` output now occurs again in a few tests because the panic payload is `ExplicitBug` (which std doesn't know about) rather than `String`. That might be worth addressing in the future but it would require a different/additional mechanism and is beyond the scope of this PR.

rustbot · 2026-09-18T05:45:37Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot · 2026-09-18T05:45:38Z

⚠️ Warning ⚠️

There are issue links (such as #123) in the commit messages of the following commits.
Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
- 0e617d4

nnethercote · 2026-09-18T05:47:08Z

I've updated the code. It now fixes the source locations, including a new case that was degraded by #161873. The Box<dyn Any> output is still present; fixing that is harder.

rustbot assigned mejrs Sep 16, 2026

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 Sep 16, 2026

This comment has been minimized.

Sign in to view

nnethercote force-pushed the fix-emit_bug branch from d3786b6 to 4239b50 Compare September 17, 2026 00:34

This comment has been minimized.

Sign in to view

nnethercote force-pushed the fix-emit_bug branch from 4239b50 to 882d803 Compare September 17, 2026 02:11

This comment has been minimized.

Sign in to view

RalfJung reviewed Sep 17, 2026

View reviewed changes

nnethercote added 2 commits September 18, 2026 15:44

Add a new -Ztrack-diagnostics test

6d00f27

It covers a case that isn't currently covered: `-Ztrack-diagnostics` in combination with a `span_bug!` ICE. Notably, the "created at" line mentions `callbacks.rs`, which is the wrong location. This will be fixed in the next commit.

nnethercote force-pushed the fix-emit_bug branch from 882d803 to 0e617d4 Compare September 18, 2026 05:45

Uh oh!

Conversation

nnethercote commented Sep 16, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Sep 17, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

RalfJung Sep 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Sep 17, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Sep 17, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Sep 17, 2026

Choose a reason for hiding this comment

Uh oh!

mejrs commented Sep 17, 2026

Uh oh!

nnethercote commented Sep 17, 2026

Uh oh!

rustbot commented Sep 18, 2026

Uh oh!

rustbot commented Sep 18, 2026

Uh oh!

nnethercote commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

nnethercote commented Sep 16, 2026 •

edited by rustbot

Loading

RalfJung Sep 17, 2026 •

edited by rustbot

Loading

nnethercote Sep 17, 2026 •

edited

Loading