Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recent change causes assertion failure in type checker #22781

Closed
dylanede opened this issue Feb 24, 2015 · 2 comments
Closed

Recent change causes assertion failure in type checker #22781

dylanede opened this issue Feb 24, 2015 · 2 comments
Labels
A-lifetimes Area: lifetime related A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

Comments

@dylanede
Copy link
Contributor

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 Aatch added the A-typesystem Area: The type system label Feb 25, 2015
@Aatch
Copy link
Contributor

Aatch commented Feb 25, 2015

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

@Aatch Aatch added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ A-lifetimes Area: lifetime related labels Feb 25, 2015
@tamird
Copy link
Contributor

tamird commented Apr 22, 2015

Still ICEs.

@apasel422 apasel422 mentioned this issue Oct 24, 2015
bors added a commit that referenced this issue Oct 25, 2015
Closes #22781.
Closes #23891.
Closes #24956.
Closes #25145.
Closes #25693.
Closes #26095.
Closes #26459.
Closes #27320.
Closes #27895.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related A-typesystem Area: The type system I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

3 participants