ICE "no enclosing scope" with cross-crate map

[alexcrichton]

Given these two files:

// foo.rs
#[link(name="foo",vers="0.0")];
#[crate_type = "lib"];
use std::hashmap::HashMap;

pub type map = @mut HashMap<uint, uint>;

// end of foo.rs

// bar.rs
extern mod foo;

fn foo(a: foo::map) {
    if false {
        fail!();
    } else {
        let _b = a.get(&2); // error may for this line; doesn't happen if "let _b" is omitted
    }
}

fn main() {}

// end of bar.rs

Yield this result:

$ rustc foo.rs && rustc -L . bar.rs
warning: no debug symbols in executable (-arch x86_64)
error: internal compiler error: no enclosing scope with id 18

[catamorphism]

Reproduced with 0252c30 . Nominating for milestone 5, production-ready.

[jbclements]

related to #3860 ?

[graydon]

accepted for production-ready milestone

[graydon]

relative of #4539

[nikomatsakis]

Dup / consequence of #4539

[pnkfelix]

Visiting for triage email 2013-07-22. ICE still occurs.

@nikomatsakis when you said its a "Dup / consequence of #4539", which is a pull request (PR) that has been closed, did you mean that this bug was injected by the code in that PR? Or something that should have been fixed by that PR and was not? I'm just trying to understand how one can claim that the two are duplicates when one is closed and other is clearly reproducible.

[pnkfelix]

(perhaps @nikomatsakis 's comment is related to his feedback on PR #4539 ...)

[nikomatsakis]

tbh I'm not entirely sure what I meant anymore. @pnkfelix can you update the example (I presume you have an updated vesion lying around) and I will re-investigate?

[pnkfelix]

@nikomatsakis yeah no problem, I forgot that I did have to do a teensy bit of updating.

[pnkfelix]

(oh wait, this might be fixed now; my earlier tests were using a build from July 10th. double-checking now.)

[pnkfelix]

@nikomatsakis I updated the test case in the description.

The bug became more difficult to expose sometime between July 16 (commit a317584 ) and July 17 (commit a93244d ), based on a coarse bisection.

I found a small perturbation of the source that continues to expose the bug.

(The original version had the line that exposes the bug in dead code before; I suspect that commit 4797dd4 may thus have masked the bug. The interesting thing is that changes such as copying the same line into both branches of the if-statement also masked the bug, as does inverting the branch-order (and condition to match), which should be a semantics-preserving transformation; some of these masking-effects only started becoming effective also between July 16 and July 17th, which is really interesting.)

Anyway, the bug remains.

[nikomatsakis]

I did make some changes in the new borrow checker work that should have addressed this bug, but they were not perfect. The proper fix is (I suspect, I haven't looked too closely) #6248

[alexcrichton]

Sadly this bug still exists :(

[alexcrichton]

This appears to be fixed. Or at least I can't write @mut any more and @ doesn't yield an error.

Flagging as needstest.

[nikomatsakis]

This is quickly becoming irrelevant, I suspect, as we remove the special cases concerning @ from borrow checker and trans.