ICE: "broken MIR in DefId" when assigning mismatched closure to FnMut

[earthengine]

The following code

#![feature(unboxed_closures)]

trait Lt<'a> {
    type T;
}
impl<'a> Lt<'a> for () {
    type T = ();
}

fn main() {
    let v:<() as Lt<'_>>::T = ();
    let f:&mut FnMut<(_,),Output=()> = &mut |_:<() as Lt<'_>>::T|{};
    f(v);
}

causes panic with message

cannot access a scoped thread local variable without calling `set` first

which is irrelevant to the code. Simply modify link_binary function in src\librustc_codegen_llvm\back\link.rs to make it panic before return, will then output some result that says

query stack during panic:
end of query stack
error: internal compiler error: broken MIR in DefId(0/0:7 ~ hrtb_fn_parameters[317d]::main[0]) (_7 = &mut (*_2)): bad assignment (&mut dyn std::ops::FnMut(()) = &mut dyn std::ops::FnMut(<() as Lt<'_>>::T)): NoSolution
  --> src/test\run-pass\hrtb-fn-parameters.rs:23:5
   |
23 |     f(v);
   |   

This is a variation of #53420 aka #29997, but is more serious and we should fix this first to make it at least emit the real error.

The proper fix of this issue, is NOT to make the code above compile; instead, it should give ICE with proper messages instead of something irrelevant so that we ensure we can get useful information from ICEs all the time, and the ICE is to be fixed after #53420 aka #29997.

[earthengine]

New error messages after PR #53624 :

error: internal compiler error: broken MIR in DefId(0/0:7 ~ playground[3845]::main[0]) (_7 = &mut (*_2)): bad assignment (&mut dyn std::ops::FnMut(()) = &mut dyn std::ops::FnMut(<() as Lt<'_>>::T)): NoSolution
  --> src/main.rs:13:5
   |
13 |     f(v);
   | 

[matthewjasper]

Marking with A-NLL since this is an issue with MIR typeck, even though this happens without nll.

[pnkfelix]

self-assigning for preliminary investigation

[pnkfelix]

Discussed with @nikomatsakis. He theorizes it is part of collection of bugs around normalization. Its not really an A-NLL thing. So I'm removing that label.

[pnkfelix]

the bug described here should block any hypothetical stabilization of unbox closures, cc: #29625

but since that is an unstable feature, and the bug here seems isolated to people making use of that feature, I'm going to triage this as P-medium for now.

[JohnTitor]

Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.