Skip to content

ICE: No move_errors should be allowed in MIR borrowck #70934

Closed
@jurkstas

Description

@jurkstas

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

Activity

jonas-schievink

jonas-schievink commented on Apr 8, 2020

@jonas-schievink
Contributor

Important detail: Only happens on the develop branch, not master

added
C-bugCategory: This is a bug.
I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
on Apr 8, 2020
jonas-schievink

jonas-schievink commented on Apr 8, 2020

@jonas-schievink
Contributor

(bisecting)

jurkstas

jurkstas commented on Apr 8, 2020

@jurkstas
Author

Important detail: Only happens on the develop branch, not master

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

jonas-schievink commented on Apr 8, 2020

@jonas-schievink
Contributor

Ah, I see

jonas-schievink

jonas-schievink commented on Apr 8, 2020

@jonas-schievink
Contributor

regression in nightly-2019-08-17

f7af19c...bdfd698

spastorino

spastorino commented on Apr 8, 2020

@spastorino
Member

@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

rustbot commented on Apr 8, 2020

@rustbot
Collaborator

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

Mark-Simulacrum commented on Apr 11, 2020

@Mark-Simulacrum
added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Apr 11, 2020
Centril

Centril commented on Apr 13, 2020

@Centril
Contributor

Looks like this compiles but it shouldn't:

struct S;

fn foo() {
    &([S][0],);
}

Dumping the MIR for this you get:

fn  foo() -> () {
    let mut _0: ();                      // return place in scope 0 at src/lib.rs:3:10: 3:10
    let _1: &(S,);                       // in scope 0 at src/lib.rs:4:5: 4:15
    let mut _2: &(S,);                   // in scope 0 at src/lib.rs:4:5: 4:15

    bb0: {
        StorageLive(_1);                 // bb0[0]: scope 0 at src/lib.rs:4:5: 4:15
        _2 = const foo::promoted[0];     // bb0[1]: scope 0 at src/lib.rs:4:5: 4:15
                                         // ty::Const
                                         // + ty: &(S,)
                                         // + val: Unevaluated(DefId(0:5 ~ playground[4e22]::foo[0]), [], Some(promoted[0]))
                                         // mir::Constant
                                         // + span: src/lib.rs:4:5: 4:15
                                         // + literal: Const { ty: &(S,), val: Unevaluated(DefId(0:5 ~ playground[4e22]::foo[0]), [], Some(promoted[0])) }
        _1 = _2;                         // bb0[2]: scope 0 at src/lib.rs:4:5: 4:15
        StorageDead(_1);                 // bb0[3]: scope 0 at src/lib.rs:4:15: 4:16
        return;                          // bb0[4]: scope 0 at src/lib.rs:5:2: 5:2
    }
}

promoted[0] in  foo: &(S,) = {
    let mut _0: &(S,);                   // return place in scope 0 at src/lib.rs:4:5: 4:15
    let mut _1: (S,);                    // in scope 0 at src/lib.rs:4:6: 4:15
    let mut _2: S;                       // in scope 0 at src/lib.rs:4:7: 4:13
    let mut _3: [S; 1];                  // in scope 0 at src/lib.rs:4:7: 4:10
    let mut _4: S;                       // in scope 0 at src/lib.rs:4:8: 4:9
    let mut _5: usize;                   // in scope 0 at src/lib.rs:4:11: 4:12

    bb0: {
        _3 = [move _4];                  // bb0[0]: scope 0 at src/lib.rs:4:7: 4:10
        _5 = const 0usize;               // bb0[1]: scope 0 at src/lib.rs:4:11: 4:12
                                         // ty::Const
                                         // + ty: usize
                                         // + val: Value(Scalar(0x0000000000000000))
                                         // mir::Constant
                                         // + span: src/lib.rs:4:11: 4:12
                                         // + literal: Const { ty: usize, val: Value(Scalar(0x0000000000000000)) }
        _2 = move _3[_5];                // bb0[2]: scope 0 at src/lib.rs:4:7: 4:13
        (_1.0: S) = move _2;             // bb0[3]: scope 0 at src/lib.rs:4:6: 4:15
        _0 = &_1;                        // bb0[4]: scope 0 at src/lib.rs:4:5: 4:15
        return;                          // bb0[5]: scope 0 at src/lib.rs:4:5: 4:15
    }
}

Presumably, what should happen here is:

error[E0508]: cannot move out of type `[S; 1]`, a non-copy array
 --> src/lib.rs:4:6
  |
4 |    &([S][0],);
  |      ^^^^^^
  |      |
  |      cannot move out of here
  |      move occurs because value has type `S`, which does not implement the `Copy` trait

The delay_span_bug occurs here:

impl<'tcx> MirPass<'tcx> for ElaborateDrops {
    fn run_pass(&self, tcx: TyCtxt<'tcx>, src: MirSource<'tcx>, body: &mut BodyAndCache<'tcx>) {
        debug!("elaborate_drops({:?} @ {:?})", src, body.span);

        let def_id = src.def_id();
        let param_env = tcx.param_env(src.def_id()).with_reveal_all();
        let move_data = match MoveData::gather_moves(body, tcx, param_env) {
            Ok(move_data) => move_data,
            Err((move_data, _)) => {
                tcx.sess.delay_span_bug(
                    body.span,
                    "No `move_errors` should be allowed in MIR borrowck",
                );
                move_data
            }
        };

cc @oli-obk @matthewjasper

spastorino

spastorino commented on Apr 13, 2020

@spastorino
Member

This issue is already prioritized as P-high removing I-prioritize label.

removed
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Apr 13, 2020
oli-obk

oli-obk commented on Apr 14, 2020

@oli-obk
Contributor

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

Centril commented on Apr 14, 2020

@Centril
Contributor

The error is constructed here:

/// Signal an error due to an attempt to move out of the interior
/// of an array or slice. `is_index` is None when error origin
/// didn't capture whether there was an indexing operation or not.
crate fn cannot_move_out_of_interior_noncopy(
&self,
move_from_span: Span,
ty: Ty<'_>,
is_index: Option<bool>,
) -> DiagnosticBuilder<'cx> {
let type_name = match (&ty.kind, is_index) {
(&ty::Array(_, _), Some(true)) | (&ty::Array(_, _), None) => "array",
(&ty::Slice(_), _) => "slice",
_ => span_bug!(move_from_span, "this path should not cause illegal move"),
};
let mut err = struct_span_err!(
self,
move_from_span,
E0508,
"cannot move out of type `{}`, a non-copy {}",
ty,
type_name,
);
err.span_label(move_from_span, "cannot move out of here");
err
}

which is called here:
self.cannot_move_out_of_interior_noncopy(span, ty, Some(*is_index))

and here:
self.cannot_move_out_of_interior_noncopy(span, ty, None)

oli-obk

oli-obk commented on Apr 14, 2020

@oli-obk
Contributor

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

oli-obk commented on Apr 14, 2020

@oli-obk
Contributor

alternatively we just run the gather_moves logic on promoteds instead of full borrowck, as the latter may have a significant perf impact.

added 2 commits that reference this issue on May 4, 2020

Rollup merge of rust-lang#71587 - matthewjasper:promoted-move-errors,…

043d1f3

Rollup merge of rust-lang#71587 - matthewjasper:promoted-move-errors,…

4bde46e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-borrow-checkerArea: The borrow checkerC-bugCategory: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ICEBreaker-Cleanup-CrewHelping to "clean up" bugs with minimal examples and bisectionsP-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.glacierICE tracked in rust-lang/glacier.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @spastorino@oli-obk@Centril@jonas-schievink@steffahn

    Issue actions

      ICE: No `move_errors` should be allowed in MIR borrowck · Issue #70934 · rust-lang/rust