move bug and span_bug macros to rustc_span by mejrs · Pull Request #161873 · rust-lang/rust

mejrs · 2026-08-27T14:26:44Z

This allows them to be used without depending on rustc_middle.

This is done by using a rustc_interface callback so that, if the callback is set, a internal compiler error diagnostic is printed through that. After that the panic is initiated.

r? @jdonszelmann @bjorn3

rustbot · 2026-08-27T14:26:49Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

changes to the core type system

cc @lcnr

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to constck

cc @fee1-dead

Some changes occurred in coverage instrumentation.

cc @Zalathar

changes to the core type system

cc @lcnr

Some changes occurred in compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs

cc @ZuseZ4

Some changes occurred in compiler/rustc_codegen_llvm/src/builder/autodiff.rs

cc @ZuseZ4

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in match lowering

cc @Nadrieril

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

HIR ty lowering was modified

cc @fmease

rustbot · 2026-08-27T14:26:52Z

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

GuillaumeGomez · 2026-08-27T14:27:46Z

Neat. :)

@bjorn3

Mark `extern_item_impls` feature as incomplete context: rust-lang#161873 (comment) > If they are so unstable, maybe they should have a separate feature gate that's marked as `incomplete`. Or the entire `extern_item_impls` should be marked "incomplete". I think it's just best to mark the entire thing as incomplete for now. Later, when the implementation matures we can consider removing the incompleteness or splitting the feature in unstable and incomplete parts. r? @bjorn3 @RalfJung

@bjorn3

Mark `extern_item_impls` feature as incomplete context: rust-lang#161873 (comment) > If they are so unstable, maybe they should have a separate feature gate that's marked as `incomplete`. Or the entire `extern_item_impls` should be marked "incomplete". I think it's just best to mark the entire thing as incomplete for now. Later, when the implementation matures we can consider removing the incompleteness or splitting the feature in unstable and incomplete parts. r? @bjorn3 @RalfJung

@bjorn3

Mark `extern_item_impls` feature as incomplete context: rust-lang#161873 (comment) > If they are so unstable, maybe they should have a separate feature gate that's marked as `incomplete`. Or the entire `extern_item_impls` should be marked "incomplete". I think it's just best to mark the entire thing as incomplete for now. Later, when the implementation matures we can consider removing the incompleteness or splitting the feature in unstable and incomplete parts. r? @bjorn3 @RalfJung

@bjorn3

Rollup merge of #161891 - mejrs:eii_incomplete, r=RalfJung Mark `extern_item_impls` feature as incomplete context: #161873 (comment) > If they are so unstable, maybe they should have a separate feature gate that's marked as `incomplete`. Or the entire `extern_item_impls` should be marked "incomplete". I think it's just best to mark the entire thing as incomplete for now. Later, when the implementation matures we can consider removing the incompleteness or splitting the feature in unstable and incomplete parts. r? @bjorn3 @RalfJung

rustbot · 2026-08-28T22:31:21Z

rustc_errors::annotate_snippet_emitter_writer was changed

cc @Muscraft

rustbot · 2026-08-28T22:38:05Z

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

tiif · 2026-09-09T11:59:47Z

I will only be able to review this on Saturday. If this is bitrotty, feel free to re-roll another reviewer :>

mejrs · 2026-09-09T21:10:37Z

I will only be able to review this on Saturday. If this is bitrotty, feel free to re-roll another reviewer :>

That's fine, it's best to merge these bitrotty prs during the weekend anyway.

tiif · 2026-09-12T13:26:43Z

I am slowly reviewing this, a question that came to mind is what is the motivation of moving these macros to rustc_span? Instinctively I think rustc_span is a better place for these macros, but I wonder if there is other reason that I didn't know.

mejrs · 2026-09-12T15:55:57Z

what is the motivation of moving these macros to rustc_span?

It allows us to use span_bug without needing to depend on rustc_middle, so it will become available in rustc_span itself, parsing, attribute parsing, macro expansion etc. And span_bug is nice because it tells us what the compiler was looking at when it panicked.

rustbot · 2026-09-12T21:10:43Z

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.

tiif

Sorry for the delay and thanks for working on this! I feel this PR is good, but there are a few things that I want to figure out before the final approval.

View changes since this review

tiif · 2026-09-13T11:14:42Z

+/// If the bug should only be emitted when compilation didn't fail,
+/// [`DiagCtxtHandle::span_delayed_bug`] may be useful.
+///
+/// [`DiagCtxtHandle::span_delayed_bug`]: ../rustc_errors/struct.DiagCtxtHandle.html#method.span_delayed_bug


This path doesn't seem correct as ../ will be compiler/rustc_span/, where the rustc_errors path is compiler/rustc_errors. Also, relative path can be confusing at times, so I think it is nicer to keep the original representation rustc_errors::DiagCtxtHandle::span_delayed_bug.

Oh right, thanks. fixed.

I think it is nicer to keep the original representation rustc_errors::DiagCtxtHandle::span_delayed_bug.

that can't be done, rustc_errors depends on rustc_span so this would be a circular dependency,

tiif · 2026-09-13T11:44:14Z

+    tls::with_opt(move |tcx| {
+        if let Some(tcx) = tcx {
+            let message = format!("{location}: {args}");
+            if let Some(span) = span {


In what case tcx will be none here, and what will happen if that's the case?

That can happen if the compiler hasn't initialized, like when running unit tests in individual rustc_* crates for example. If not then it will just do what bug! does, which is panicking with a custom message.

tiif · 2026-09-13T12:12:27Z

+#[track_caller]
+pub fn bug_impl(span: Option<Span>, args: fmt::Arguments<'_>, location: &Location<'_>) -> ! {
+    (*EMIT_BUG_DIAGNOSTIC)(span, args, location);
+    panic!("{args}")


Does this mean that the call to bug_impl will always panic? This seems different from previous behaviour, may I know why?

It's the same as what opt_span_bug_fmt did, the panic calls are implicit there because TyCtxt::{span_bug, bug} bottoms out at panicking.

previous logic:

if there is a tcx, create a Bug diagnostic which panics when it's emitted

if there is no tcx, panic

current logic:

if there is a tcx, emit a diagnostic

panic

the latter approach also plays much nicer with backtraces because otherwise the panic comes from deep inside the diagnostics machinery.

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Aug 27, 2026

rustbot assigned jdonszelmann Aug 27, 2026

mejrs force-pushed the bug branch from d343ad6 to 7ff2483 Compare August 27, 2026 14:30