Closed
Description
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
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
auto merge of #5523 : alexcrichton/rust/less-oldmap, r=thestinger
catamorphism commentedon May 23, 2013
Reproduced with 0252c30 . Nominating for milestone 5, production-ready.
jbclements commentedon May 23, 2013
related to #3860 ?
graydon commentedon May 23, 2013
accepted for production-ready milestone
graydon commentedon May 23, 2013
relative of #4539
nikomatsakis commentedon May 23, 2013
Dup / consequence of #4539
pnkfelix commentedon Jul 25, 2013
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 commentedon Jul 25, 2013
(perhaps @nikomatsakis 's comment is related to his feedback on PR #4539 ...)
nikomatsakis commentedon Jul 25, 2013
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 commentedon Jul 25, 2013
@nikomatsakis yeah no problem, I forgot that I did have to do a teensy bit of updating.
pnkfelix commentedon Jul 25, 2013
(oh wait, this might be fixed now; my earlier tests were using a build from July 10th. double-checking now.)
pnkfelix commentedon Jul 26, 2013
@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 commentedon Jul 26, 2013
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 commentedon Sep 6, 2013
Sadly this bug still exists :(
10 remaining items