Recent change causes assertion failure in type checker

[dylanede]

First, sorry that I can't pinpoint which change caused this ICE to pop up - but the best guess I can give is somewhere in the last 2 weeks - I just updated to a recent nightly over the weekend. This is still reproducible on master.

The following code produces an ICE:

use std::collections::HashMap;
use std::collections::hash_map::Entry::Vacant;

pub fn foo() {
    type F = Box<Fn(&()) + 'static>;
    let mut map: HashMap<(), F> = HashMap::new();
    let x: &mut F = match map.entry(()) {
        Vacant(_) => unimplemented!(),
        _ => unimplemented!()
    };
}

The error message is:

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: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: !ty::type_needs_infer(ty)', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/librustc_typeck/lib.rs:149

Obviously the unimplemented!() code is just a placeholder, and the same issue occurs when the match statement is used as might be expected to get a mutable reference from an entry.

This is the smallest test case I have come up with. It seems to depend on the match statement existing with at least two arms and its result being used in some way, as well as the higher-ranked lifetime bound in the closure type F.

This bug is really hindering a project I am working on.

[Aatch]

Ok, so after a fair bit of investigation, I've found that this is a pretty complex bug. Fortunately, it's trivial to work around, for the example here doing let x = match map.entry() { ... }; let x : &mut F = x; works.

The issue seems to be related to coercions, though I can't quite figure out why your example fails, but my workaround, well works. The core of the issue is that the type of F (or more accurately, the version of F that is assigned to the match statement) seems to loose it's 'static bound at some point and it gets replaced with an inferred region. Presumably this happens after region inference, but I'm not familiar enough with the code to be sure.

cc @nikomatsakis @pnkfelix

[tamird]

Still ICEs.