Repository navigation
Const generic ICE: assertion failed: key.value.promoted.is_none() #61432
Description
Promotion of const generic parameters causes the compiler to crash.
#![feature(const_generics)]
fn promote<const N: i32>() {
// works:
//
// let n = N;
// &n;
&N;
}
fn main() {
promote::<0>();
}$ RUST_BACKTRACE=1 rustc +nightly promotion_const_generics_ice.rs
warning: the feature `const_generics` is incomplete and may cause the compiler to crash
--> promotion_const_generics_ice.rs:1:12
|
1 | #![feature(const_generics)]
| ^^^^^^^^^^^^^^
thread 'rustc' panicked at 'assertion failed: key.value.promoted.is_none()', src/librustc_mir/const_eval.rs:577:17
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/libunwind.rs:97
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.25/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:47
3: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:36
4: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:197
5: std::panicking::default_hook
at src/libstd/panicking.rs:211
6: rustc::util::common::panic_hook
7: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
8: std::panicking::begin_panic
9: rustc_mir::const_eval::const_eval_provider
10: rustc::ty::query::__query_compute::const_eval
11: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::const_eval>::compute
12: rustc::dep_graph::graph::DepGraph::with_task_impl
13: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
14: rustc_mir::monomorphize::collector::collect_items_rec
15: rustc_mir::monomorphize::collector::collect_items_rec
16: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
17: rustc::util::common::time
18: rustc_mir::monomorphize::collector::collect_crate_mono_items
19: rustc::util::common::time
20: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
21: rustc::ty::query::__query_compute::collect_and_partition_mono_items
22: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::collect_and_partition_mono_items>::compute
23: rustc::dep_graph::graph::DepGraph::with_task_impl
24: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
25: rustc_codegen_ssa::base::codegen_crate
26: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
27: rustc::util::common::time
28: rustc_interface::passes::start_codegen
29: rustc::ty::context::tls::enter_global
30: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
31: rustc_interface::passes::create_global_ctxt::{{closure}}
32: rustc_interface::passes::BoxedGlobalCtxt::enter
33: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::ongoing_codegen
34: rustc_interface::interface::run_compiler_in_existing_thread_pool
35: std::thread::local::LocalKey<T>::with
36: scoped_tls::ScopedKey<T>::set
37: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
query stack during panic:
#0 [const_eval] const-evaluating + checking `promote`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: internal compiler error: unexpected panic
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.37.0-nightly (7840a0b75 2019-05-31) running on x86_64-unknown-linux-gnu
Activity
varkor commentedon Jun 1, 2019
This is happening here:
https://github.com/rust-lang/rust/blob/73b67c255a113fd0f94e00eb51be2f1eb11ce39a/src/librustc_mir/const_eval.rs#L572-L576
cc @oli-obk
czipperz commentedon Jun 2, 2019
So what is the expected behavior here?
oli-obk commentedon Jun 2, 2019
@varkor why shouldn't we? Like ok, we shouldn't right now, but why shouldn't ever? We are already promoting
&std::mem::size_of::<T>()which seems just as problematic. This is just a limitation of the miri engine, that I wager will be simple to solve. Especially when looking at where this is happening (in thecollector). Everything is monomorphic at that point I believe?varkor commentedon Jun 2, 2019
Ah, that is true. It should be okay, you're right.
oli-obk commentedon Jun 2, 2019
Ok, awesome, I was worried for a bit that we screwed up promotion. Now let's figure out what's going wrong here.
As far as I can tell, the only way to get to a
TooGenericis by substituting and ending up with an unsubstituted (needs_subst) value. Our substitution machinery is a little whacky as clippy has already encountered, but ifsize_ofcalls can get promoted, I don't know why const generics would go down a different path. We'll need to run the repro from this issue through a rustc withRUSTC_LOG=rustc_mir::interpret,rustc::mir::interpret RUST_CTFE_BACKTRACE=immediateto get some detailed info on those errors.jplatte commentedon Jun 11, 2019
This also happens when passing a const generic variable (directly) to
println!and friends.oli-obk commentedon Jun 21, 2019
🤣 uh, so, I found this
rust/src/librustc_mir/interpret/operand.rs
Line 526 in 811b996
Basically the fix is to call
self.monomorphizeonconstant.literalinrust/src/librustc_mir/interpret/operand.rs
Line 497 in 811b996
rust/src/librustc_mir/interpret/operand.rs
Line 526 in 811b996
bug!callThis change is blocked on the
eval_context.rschanges from #62012varkor commentedon Jun 25, 2019
Making this change:
results in:
while compiling rustc.
Details
oli-obk commentedon Jun 25, 2019
heh, one can always trust in
libapfloatto expose const eval bugscan you run with
RUSTC_LOG=rustc_mir::interpretand dump that log, too? It looks to me like theinstancefield of theFramehas the wrongSubstsJohnTitor commentedon Jun 25, 2019
@oli-obk FWIW I got this log.
oli-obk commentedon Jun 25, 2019
ah, unfortunately the rustc you're using is built without debug flags, so we're only getting
INFOlevel logs.JohnTitor commentedon Jun 25, 2019
Oops. If no one has posted yet, I'll paste later.
varkor commentedon Jun 25, 2019
Here's the lower section. I can post more if this doesn't contain all the relevant information, but the full trace is long.
Details
oli-obk commentedon Jun 25, 2019
try dumping the stackframe size, the
instance,tandsubstsinrust/src/librustc_mir/interpret/eval_context.rs
Line 338 in 811b996
[]as substs, but it should be[f32], maybe we're looking at the wrong thingvarkor commentedon Jun 30, 2019
@JohnTitor: you're welcome to take this issue. I'm not sure I'll have time to debug this soon.
JohnTitor commentedon Jun 30, 2019
@oli-obk How we try dumping the stackframe size?
oli-obk commentedon Jul 14, 2019
you can use
self.frame.len()I suppose and print that viadebug!test: add test for rust-lang#61432.
Rollup merge of rust-lang#63497 - eddyb:miri-subst, r=oli-obk
Auto merge of #63497 - eddyb:miri-subst, r=oli-obk