panic on failed dead code analysis

[lu-zero]

playground

const FOO: [u8; 2] = [42; 2];

fn main() {
    if FOO.len() > 2 {
        println!(" {}", FOO[3]);
    }
}

I would expect that the constant propagation pass would prune the println! and possibly issue a warning about it.

the result instead:

thread 'main' panicked at 'Tried to access element 3 of array/slice with length 2', librustc_mir/interpret/place.rs:265:17
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:481
   6: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   7: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:346
   8: rustc_mir::interpret::place::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::mplace_projection
   9: rustc_mir::interpret::place::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::place_projection
  10: rustc_mir::interpret::place::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::eval_place
  11: rustc_mir::interpret::step::<impl rustc_mir::interpret::eval_context::EvalContext<'a, 'mir, 'tcx, M>>::run
  12: rustc_mir::const_eval::eval_body_using_ecx
  13: rustc_mir::const_eval::const_eval_provider
  14: rustc::ty::query::__query_compute::const_eval
  15: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::const_eval<'tcx>>::compute
  16: rustc::dep_graph::graph::DepGraph::with_task_impl
  17: rustc::ty::context::tls::with_related_context
  18: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  19: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  20: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  21: rustc::ty::query::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::const_eval
  22: rustc_mir::monomorphize::collector::collect_items_rec
  23: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
  24: rustc::util::common::time
  25: rustc_mir::monomorphize::collector::collect_crate_mono_items
  26: rustc::util::common::time
  27: rustc_codegen_llvm::base::collect_and_partition_mono_items
  28: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::collect_and_partition_mono_items<'tcx>>::compute
  29: rustc::dep_graph::graph::DepGraph::with_task_impl
  30: rustc::ty::context::tls::with_related_context
  31: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  32: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  33: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  34: rustc_codegen_llvm::base::codegen_crate
  35: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  36: rustc::util::common::time
  37: rustc_driver::driver::phase_4_codegen
  38: rustc_driver::driver::compile_input::{{closure}}
  39: rustc::ty::context::tls::enter_context
  40: <std::thread::local::LocalKey<T>>::with
  41: rustc::ty::context::TyCtxt::create_and_enter
  42: rustc_driver::driver::compile_input
  43: rustc_driver::run_compiler_with_pool
  44: <scoped_tls::ScopedKey<T>>::set
  45: rustc_driver::run_compiler
  46: <scoped_tls::ScopedKey<T>>::set
  47: syntax::with_globals
  48: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  49: rustc_driver::run
  50: rustc_driver::main
  51: std::rt::lang_start::{{closure}}
  52: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  53: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  54: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  55: main
  56: __libc_start_main
  57: <unknown>
query stack during panic:
#0 [const_eval] const-evaluating `main`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: aborting due to previous error


error: internal compiler error: unexpected panic

[Havvy]

This happens only under the 2018 edition, but does also happen in beta. Given that it does not happen in the 2015 edition, I'm not adding the regression tag. I feel like I should be adding the 2018 edition preview tag, but I'm not sure it applies. It also happens if you add #![allow(const_error)].

[lu-zero]

It is also a surprising behavior in 2015, but that is probably due the fact the const-propagation pass and the unreachable code analysis are happening in a way different from clang and gcc.

[lu-zero]

Now it does not crash anymore but still produces a spurious error instead of a warning:

error: index out of bounds: the len is 2 but the index is 3
 --> src/main.rs:5:25
  |
5 |         println!(" {}", FOO[3]);
  |                         ^^^^^^
  |
  = note: #[deny(const_err)] on by default

[Havvy]

That isn't spurious. Lint errors can still happen in dead code.

[lu-zero]

It is a surprising behavior compared to other compilers, I wonder where it could be documented and/or if would be acceptable to have an option disable it.

And in any case would be good to always warn about dead code even if here is an error over a lint in it.

[flip111]

error: index out of bounds: the len is 2 but the index is 3

Prefer:

warning in dead code: index out of bounds: the len is 2 but the index is 3

[oli-obk]

This is hard to analyze. This issue will be solved when our const propagator gets smarter. Even though this is a simple example (from a human perspective), there are essentially infinite more complex examples that we currently lint about but a smart enough compiler would not. I'm not sure where to draw the line.

[RodBurman]

Situation has not materially changed in 4+ years

error: this operation will panic at runtime
 --> src/main.rs:5:25
  |
5 |         println!(" {}", FOO[3]);
  |                         ^^^^^^ index out of bounds: the length is 2 but the index is 3
  |
  = note: `#[deny(unconditional_panic)]` on by default

Obtained with:

cargo 1.82.0 (8f40fc59f 2024-08-21)
release: 1.82.0
commit-hash: 8f40fc59fb0c8df91c97405785197f3c630304ea
commit-date: 2024-08-21
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w 11 Sep 2023
os: Mac OS 15.1.1 [64-bit]