Skip to content
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

const fn ICE on nightly #65348

Closed
DutchGhost opened this issue Oct 12, 2019 · 2 comments · Fixed by #65389
Closed

const fn ICE on nightly #65348

DutchGhost opened this issue Oct 12, 2019 · 2 comments · Fixed by #65389
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@DutchGhost
Copy link
Contributor

DutchGhost commented Oct 12, 2019

The following ICE's on nightly only:

struct ArrayType<T>(T);

impl <T> ArrayType<T> {
    const ARRAY: [T; 0] = [];
}

pub const fn bug<T>() ->  &'static T {
    &ArrayType::<T>::ARRAY[0]
}

fn main() {
    bug::<i32>();
}
Backtrace:
[ERROR rustc_mir::transform::qualify_consts] old validator: []
[ERROR rustc_mir::transform::qualify_consts] new validator: [(src/main.rs:8:6: 8:27, "LiveDrop")]
error: internal compiler error: src/librustc_mir/transform/qualify_consts.rs:1038: Disagreement between legacy and dataflow-based const validators.
    After filing an issue, use `-Zsuppress-const-validation-back-compat-ice` to compile your code.
 --> src/main.rs:7:1
  |
7 | / pub const fn bug<T>() ->  &'static T {
8 | |     &ArrayType::<T>::ARRAY[0]
9 | | }
  | |_^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:876:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:77
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:61
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1028
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:65
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:50
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:189
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:206
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:473
  12: std::panicking::begin_panic
  13: rustc_errors::HandlerInner::span_bug
  14: rustc_errors::Handler::span_bug
  15: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  16: rustc::ty::context::tls::with_opt::{{closure}}
  17: rustc::ty::context::tls::with_context_opt
  18: rustc::ty::context::tls::with_opt
  19: rustc::util::bug::opt_span_bug_fmt
  20: rustc::util::bug::span_bug_fmt
  21: rustc_mir::transform::qualify_consts::Checker::check_const
  22: <rustc_mir::transform::qualify_consts::QualifyAndPromoteConstants as rustc_mir::transform::MirPass>::run_pass
  23: rustc_mir::transform::run_passes
  24: rustc_mir::transform::mir_validated
  25: rustc::ty::query::__query_compute::mir_validated
  26: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::mir_validated>::compute
  27: rustc::dep_graph::graph::DepGraph::with_task_impl
  28: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  29: rustc_mir::borrow_check::mir_borrowck
  30: rustc::ty::query::__query_compute::mir_borrowck
  31: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::mir_borrowck>::compute
  32: rustc::dep_graph::graph::DepGraph::with_task_impl
  33: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  34: rustc::ty::<impl rustc::ty::context::TyCtxt>::par_body_owners
  35: rustc::util::common::time
  36: rustc_interface::passes::analysis
  37: rustc::ty::query::__query_compute::analysis
  38: rustc::dep_graph::graph::DepGraph::with_task_impl
  39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  40: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  41: rustc_interface::passes::create_global_ctxt::{{closure}}
  42: rustc_interface::passes::BoxedGlobalCtxt::enter
  43: rustc_interface::interface::run_compiler_in_existing_thread_pool
  44: std::thread::local::LocalKey<T>::with
  45: scoped_tls::ScopedKey<T>::set
  46: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.40.0-nightly (6767d9b90 2019-10-11) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type bin

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [mir_validated] processing `bug`
#1 [mir_borrowck] processing `bug`
#2 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error

error: could not compile `playground`.

This ICE is the same as reported in #64945 , however the example given there currently runs fine without any errors.

@jonas-schievink jonas-schievink added A-const-fn C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 12, 2019
@Centril
Copy link
Contributor

Centril commented Oct 12, 2019

cc @ecstatic-morse @oli-obk @eddyb

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Oct 12, 2019

As the OP notes, this is closely related to #64945. To fix that problem, zero-length arrays were special-cased so that they are never marked as indirectly mutable. However, this did not extend to projections of zero-length arrays. When compiling this code, the IndirectlyMutableLocals analysis sees a reference being taken to a place of type T, which it cannot assume is Freeze. I should be able to make the validation passes agree in this particular case by checking the type of the target of each projection along the borrowed place, suppressing the indirectly mutable annotation for the base local if any of those types are a zero-sized array.

It's unfortunate that we have to treat &VAL_OF_T and &EMPTY_ARRAY_OF_T[42] differently here, but obviously backwards compatibility must be preserved. I wonder if there's a different way to handle this. It seems like NeedsDrop::in_any_value_of_ty() should return false for an empty array?

@oli-obk oli-obk added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Oct 13, 2019
ecstatic-morse added a commit to ecstatic-morse/rust that referenced this issue Oct 13, 2019
bors added a commit that referenced this issue Oct 14, 2019
Return `false` from `needs_drop` for all zero-sized arrays.

Resolves #65348.

This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving #65348 and #64945, but obviously it has much broader implications.
@rust-lang-glacier-bot rust-lang-glacier-bot added the glacier ICE tracked in rust-lang/glacier. label Oct 15, 2019
Centril added a commit to Centril/rust that referenced this issue Oct 15, 2019
…drop, r=eddyb

Return `false` from `needs_drop` for all zero-sized arrays.

Resolves rust-lang#65348.

This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving rust-lang#65348 and rust-lang#64945, but obviously it has much broader implications.
Centril added a commit to Centril/rust that referenced this issue Oct 15, 2019
…drop, r=eddyb

Return `false` from `needs_drop` for all zero-sized arrays.

Resolves rust-lang#65348.

This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving rust-lang#65348 and rust-lang#64945, but obviously it has much broader implications.
@bors bors closed this as completed in bbcf66a Oct 16, 2019
@RalfJung RalfJung added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants