Closed
Description
I get an ICE when I try to build evolvim:
error: internal compiler error: No `move_errors` should be allowed in MIR borrowck
--> evolvim-lib\./src/lib\neat\genome\mod.rs:100:13
|
100 | InputType::Eye(EYE[2]).clone(),
| ^^^^^^^^^^^^^^^^^^^^^^
error: internal compiler error: No `move_errors` should be allowed in MIR borrowck
--> evolvim-lib\./src/lib\neat\genome\mod.rs:99:13
|
99 | InputType::Eye(EYE[1]).clone(),
| ^^^^^^^^^^^^^^^^^^^^^^
error: internal compiler error: No `move_errors` should be allowed in MIR borrowck
--> evolvim-lib\./src/lib\neat\genome\mod.rs:98:13
|
98 | InputType::Eye(EYE[0]).clone(),
| ^^^^^^^^^^^^^^^^^^^^^^
thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src\librustc_errors\lib.rs:357:17
stack backtrace:
0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
1: core::fmt::write
2: <std::io::IoSliceMut as core::fmt::Debug>::fmt
3: std::panicking::take_hook
4: std::panicking::take_hook
5: rustc_driver::report_ice
6: std::panicking::rust_panic_with_hook
7: <rustc_errors::snippet::Style as core::fmt::Debug>::fmt
8: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop
9: rustc_driver::pretty::print_after_hir_lowering
10: rustc_driver::pretty::print_after_hir_lowering
11: rustc_driver::pretty::print_after_hir_lowering
12: rustc_driver::pretty::print_after_hir_lowering
13: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
14: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
15: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
16: _rust_maybe_catch_panic
17: rustc_driver::pretty::print_after_hir_lowering
18: ZN244_$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$dyn$u20$std..error..Error$u2b$core..marker..Sync$u2b$core..marker..Send$GT$$GT$..from..StringError$u20$as$u20$core..fmt..Display$GT$3fmt17
19: std::sys::windows::thread::Thread::new
20: BaseThreadInitThunk
21: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
I tried stable, beta and nightly. All ended with an ICE.
>rustc --version --verbose
rustc 1.42.0 (b8cedc004 2020-03-09)
binary: rustc
commit-hash: b8cedc00407a4c56a3bda1ed605c6fc166655447
commit-date: 2020-03-09
host: x86_64-pc-windows-msvc
release: 1.42.0
LLVM version: 9.0
Metadata
Metadata
Assignees
Labels
Area: The borrow checkerCategory: This is a bug.Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Helping to "clean up" bugs with minimal examples and bisectionsHigh priorityRelevant to the compiler team, which will review and decide on the PR/issue.ICE tracked in rust-lang/glacier.Performance or correctness regression from one stable version to another.
Activity
jonas-schievink commentedon Apr 8, 2020
Important detail: Only happens on the
develop
branch, notmaster
jonas-schievink commentedon Apr 8, 2020
(bisecting)
jurkstas commentedon Apr 8, 2020
It happens with master branch as well if I do
cargo update
before building. Without it, it fails due to nalgebra issue before it even gets to evolvim-lib.jonas-schievink commentedon Apr 8, 2020
Ah, I see
jonas-schievink commentedon Apr 8, 2020
regression in nightly-2019-08-17
f7af19c...bdfd698
spastorino commentedon Apr 8, 2020
@jonas-schievink great :). Unsure if you're bisecting this further, anyway pinging cleanup crew in case you are not doing it further and also to see if someone is able to get an mcve.
@rustbot ping cleanup
rustbot commentedon Apr 8, 2020
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3
cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke
20 remaining items
Mark-Simulacrum commentedon Apr 11, 2020
Centril commentedon Apr 13, 2020
Looks like this compiles but it shouldn't:
Dumping the MIR for this you get:
Presumably, what should happen here is:
The
delay_span_bug
occurs here:cc @oli-obk @matthewjasper
spastorino commentedon Apr 13, 2020
This issue is already prioritized as
P-high
removingI-prioritize
label.oli-obk commentedon Apr 14, 2020
I guess we need to track down where
error[E0508]: cannot move out of type
[S; 1], a non-copy array
is emitted and make that code also look at the MIR of promoteds.We can't avoid that code from getting promoted without getting into an unfun game of whack-a-mole in the promotion code.
Centril commentedon Apr 14, 2020
The error is constructed here:
rust/src/librustc_mir/util/borrowck_errors.rs
Lines 281 to 305 in ba72b15
which is called here:
rust/src/librustc_mir/borrow_check/diagnostics/move_errors.rs
Line 258 in ba72b15
and here:
rust/src/librustc_mir/borrow_check/diagnostics/move_errors.rs
Line 331 in ba72b15
oli-obk commentedon Apr 14, 2020
hmmm... not sure what borrowck does to promoteds. I mean we basically declared all lifetimes to be static, but the same is true for the body of constants which we do run borrowck on. So... let's try to just run borrowck on promoteds and see how it goes.
oli-obk commentedon Apr 14, 2020
alternatively we just run the
gather_moves
logic on promoteds instead of full borrowck, as the latter may have a significant perf impact.Rollup merge of rust-lang#71587 - matthewjasper:promoted-move-errors,…
Rollup merge of rust-lang#71587 - matthewjasper:promoted-move-errors,…