[ICE]: `rustc` panics with some values of `diagnostic-width`

[olexander-movchan]

This happens when cargo is invoked from CMake which is launched by VS Code (via CMakeTools extension).

That makes it impossible to build a CMake project that compiles Rust dependencies from VS Code GUI if that Rust project has any warnings.

Could also be reproduced with this command:

rustc --diagnostic-width=10 --crate-type rlib rustc-ice-demo.rs

Code

rustc-ice-demo.rs:

//! `rustc` internal compiler error (ICE) demo.
//!
//! # Version
//! 
//! ```bash
//! rustc 1.95.0 (59807616e 2026-04-14)
//! binary: rustc
//! commit-hash: 59807616e1fa2540724bfbac14d7976d7e4a3860
//! commit-date: 2026-04-14
//! host: x86_64-unknown-linux-gnu
//! release: 1.95.0
//! LLVM version: 22.1.2
//! ```
//!
//! # Reproduce
//!
//! ```bash
//! rustc --diagnostic-width=10 --crate-type rlib rustc-ice-demo.rs
//! ```

struct Struct;
impl Struct {
    pub const fn new() -> Self { Self }
}

const C: Struct = Struct::new();

Note that removing comments from this file will stop the bug from reproducing (I guess because line numbers in the warnings become single digit).

Meta

rustc --version --verbose:

rustc 1.95.0 (59807616e 2026-04-14)
binary: rustc
commit-hash: 59807616e1fa2540724bfbac14d7976d7e4a3860
commit-date: 2026-04-14
host: x86_64-unknown-linux-gnu
release: 1.95.0
LLVM version: 22.1.2

Error output

warning: struct `Struct` is never constructed
  --> rustc-ice-demo.rs:21:8
   |
21 | ...ct Struct;
   |       ^^^^^^
   |
   = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default


thread 'rustc' (7387) panicked at /rustc-dev/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/slice/index.rs:1031:55:
slice index starts at 5 but ends at 3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: the compiler unexpectedly panicked. This is a bug

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.95.0 (59807616e 2026-04-14) running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type rlib

query stack during panic:
#0 [check_mod_deathness] checking deathness of variables in top-level module
#1 [analysis] running analysis passes on crate `rustc_ice_demo`
end of query stack
warning: 2 warnings emitted

Backtrace

thread 'rustc' (7463) panicked at /rustc-dev/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/slice/index.rs:1031:55:
slice index starts at 5 but ends at 3
stack backtrace:
   0:     0x7f497d59314b - <<std[e28293b1aa0f68bd]::sys::backtrace::BacktraceLock>::print::DisplayBacktrace as core[c1f1a4ba060b9bfa]::fmt::Display>::fmt
   1:     0x7f497dc1f408 - core[c1f1a4ba060b9bfa]::fmt::write
   2:     0x7f497f1683b6 - <std[e28293b1aa0f68bd]::sys::stdio::unix::Stderr as std[e28293b1aa0f68bd]::io::Write>::write_fmt
   3:     0x7f497d569238 - std[e28293b1aa0f68bd]::panicking::default_hook::{closure#0}
   4:     0x7f497d5865b3 - std[e28293b1aa0f68bd]::panicking::default_hook
   5:     0x7f497c55cc30 - std[e28293b1aa0f68bd]::panicking::update_hook::<alloc[fdfd2bd8633a6659]::boxed::Box<rustc_driver_impl[e4ca9dd5dd6cf2a8]::install_ice_hook::{closure#1}>>::{closure#0}
   6:     0x7f497d586892 - std[e28293b1aa0f68bd]::panicking::panic_with_hook
   7:     0x7f497d5692f8 - std[e28293b1aa0f68bd]::panicking::panic_handler::{closure#0}
   8:     0x7f497d560029 - std[e28293b1aa0f68bd]::sys::backtrace::__rust_end_short_backtrace::<std[e28293b1aa0f68bd]::panicking::panic_handler::{closure#0}, !>
   9:     0x7f497d56ad5d - __rustc[b7974e8690430dd9]::rust_begin_unwind
  10:     0x7f497a2de82c - core[c1f1a4ba060b9bfa]::panicking::panic_fmt
  11:     0x7f497b30875d - core[c1f1a4ba060b9bfa]::slice::index::slice_index_fail
  12:     0x7f497be7fae5 - <annotate_snippets[7d52211d2f32161f]::renderer::styled_buffer::StyledBuffer>::replace
  13:     0x7f497ef337b7 - annotate_snippets[7d52211d2f32161f]::renderer::render::render
  14:     0x7f497f181e06 - <rustc_errors[795cd5cf46ddce51]::annotate_snippet_emitter_writer::AnnotateSnippetEmitter>::emit_messages_default
  15:     0x7f497f179420 - <rustc_errors[795cd5cf46ddce51]::annotate_snippet_emitter_writer::AnnotateSnippetEmitter as rustc_errors[795cd5cf46ddce51]::emitter::Emitter>::emit_diagnostic
  16:     0x7f497f171661 - <rustc_errors[795cd5cf46ddce51]::DiagCtxtInner>::emit_diagnostic::{closure#3}
  17:     0x7f497f16f440 - rustc_interface[c8170c4b7b680ee8]::callbacks::track_diagnostic::<core[c1f1a4ba060b9bfa]::option::Option<rustc_span[e3c9a1967c4921fd]::ErrorGuaranteed>>
  18:     0x7f497f16e4ee - <rustc_errors[795cd5cf46ddce51]::DiagCtxtInner>::emit_diagnostic
  19:     0x7f497f16e39d - <rustc_errors[795cd5cf46ddce51]::DiagCtxtHandle>::emit_diagnostic
  20:     0x7f497f16e25b - <() as rustc_errors[795cd5cf46ddce51]::diagnostic::EmissionGuarantee>::emit_producing_guarantee
  21:     0x7f497e4a7656 - rustc_middle[9956b31dc9b62104]::lint::diag_lint_level::diag_lint_level_impl
  22:     0x7f497e62ee65 - <rustc_passes[6bf4acf08ac4e6d9]::dead::DeadVisitor>::lint_at_single_level
  23:     0x7f497e218254 - <rustc_passes[6bf4acf08ac4e6d9]::dead::DeadVisitor>::warn_multiple
  24:     0x7f497e217b4b - rustc_passes[6bf4acf08ac4e6d9]::dead::check_mod_deathness
  25:     0x7f497ea4af8a - rustc_query_impl[b21371cac9e22a84]::execution::try_execute_query::<rustc_middle[9956b31dc9b62104]::query::caches::DefaultCache<rustc_span[e3c9a1967c4921fd]::def_id::LocalModDefId, rustc_middle[9956b31dc9b62104]::query::erase::ErasedData<[u8; 0usize]>>, false>
  26:     0x7f497ea4a0be - rustc_query_impl[b21371cac9e22a84]::query_impl::check_mod_deathness::execute_query_non_incr::__rust_end_short_backtrace
  27:     0x7f497ea49ca4 - rustc_interface[c8170c4b7b680ee8]::passes::analysis::{closure#0}::{closure#0}::{closure#1}
  28:     0x7f497ea48ed7 - rustc_data_structures[2c167692117eb14d]::sync::parallel::par_fns
  29:     0x7f497ea48e66 - rustc_interface[c8170c4b7b680ee8]::passes::analysis::{closure#0}::{closure#0}
  30:     0x7f497ea48ed7 - rustc_data_structures[2c167692117eb14d]::sync::parallel::par_fns
  31:     0x7f497dd36ad7 - rustc_interface[c8170c4b7b680ee8]::passes::analysis
  32:     0x7f497ee40d9a - rustc_query_impl[b21371cac9e22a84]::execution::try_execute_query::<rustc_middle[9956b31dc9b62104]::query::caches::SingleCache<rustc_middle[9956b31dc9b62104]::query::erase::ErasedData<[u8; 0usize]>>, false>
  33:     0x7f497ee40b6b - rustc_query_impl[b21371cac9e22a84]::query_impl::analysis::execute_query_non_incr::__rust_end_short_backtrace
  34:     0x7f497ee5632d - rustc_interface[c8170c4b7b680ee8]::interface::run_compiler::<(), rustc_driver_impl[e4ca9dd5dd6cf2a8]::run_compiler::{closure#0}>::{closure#1}
  35:     0x7f497ee2663e - std[e28293b1aa0f68bd]::sys::backtrace::__rust_begin_short_backtrace::<rustc_interface[c8170c4b7b680ee8]::util::run_in_thread_with_globals<rustc_interface[c8170c4b7b680ee8]::util::run_in_thread_pool_with_globals<rustc_interface[c8170c4b7b680ee8]::interface::run_compiler<(), rustc_driver_impl[e4ca9dd5dd6cf2a8]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>
  36:     0x7f497ee26ca0 - <std[e28293b1aa0f68bd]::thread::lifecycle::spawn_unchecked<rustc_interface[c8170c4b7b680ee8]::util::run_in_thread_with_globals<rustc_interface[c8170c4b7b680ee8]::util::run_in_thread_pool_with_globals<rustc_interface[c8170c4b7b680ee8]::interface::run_compiler<(), rustc_driver_impl[e4ca9dd5dd6cf2a8]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>::{closure#1} as core[c1f1a4ba060b9bfa]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  37:     0x7f497ee27b2c - <std[e28293b1aa0f68bd]::sys::thread::unix::Thread>::new::thread_start
  38:     0x7f4978878759 - start_thread
  39:     0x7f49788fca4c - __clone3
  40:                0x0 - <unknown>

[cyrgani]

This sounds like a duplicate of #154258, in which case it is already fixed by #154914, which will be part of 1.96.0. Can you reproduce this with the latest beta or nightly compiler?

[olexander-movchan]

@cyrgani, thanks, seems like it has been fixed in beta, the bug doesn't reproduce on my example.

I guess this issue can be closed then.