New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panic on failed dead code analysis #54553

Open
lu-zero opened this Issue Sep 25, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@lu-zero
Contributor

lu-zero commented Sep 25, 2018

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 comment has been minimized.

Contributor

Havvy commented Sep 25, 2018

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

This comment has been minimized.

Contributor

lu-zero commented Sep 25, 2018

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

This comment has been minimized.

Contributor

lu-zero commented Oct 8, 2018

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

This comment has been minimized.

Contributor

Havvy commented Oct 8, 2018

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

@lu-zero

This comment has been minimized.

Contributor

lu-zero commented Oct 8, 2018

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

This comment has been minimized.

flip111 commented Oct 23, 2018

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