-
Notifications
You must be signed in to change notification settings - Fork 13.4k
ICE: using operand local as place #46855
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
Comments
Definitely seems to be exposed by this MIR optimization: diff --git a/rustc.main.002-014.InstCombine.before.mir b/rustc.main.002-014.InstCombine.after.mir
index 81357e1..0f5c50c 100644
--- a/rustc.main.002-014.InstCombine.before.mir
+++ b/rustc.main.002-014.InstCombine.after.mir
@@ -1,7 +1,7 @@
// MIR for `main`
// source = MirSource { def_id: DefId(0/0:5 ~ x[317d]::main[0]), promoted: None }
// pass_name = InstCombine
-// disambiguator = before
+// disambiguator = after
fn main() -> () {
let mut _0: (); // return place
@@ -238,7 +238,14 @@ fn main() -> () {
// <E2><94><94> span: x.rs:16:33: 16:34
// <E2><94><94> ty: usize
// <E2><94><94> literal: const 0usize
- _54 = Len(_32); // bb3[32]: scope 4 at x.rs:16:31: 16:35
+ _54 = const 2usize; // bb3[32]: scope 4 at x.rs:16:31: 16:35
+ // ty::Const
+ // <E2><94><94> ty: usize
+ // <E2><94><94> val: Integral(Usize(Us64(2)))
+ // mir::Constant
+ // <E2><94><94> span: x.rs:16:31: 16:35
+ // <E2><94><94> ty: usize
+ // <E2><94><94> literal: const 2usize
_55 = Lt(_53, _54); // bb3[33]: scope 4 at x.rs:16:31: 16:35
assert(move _55, "index out of bounds: the len is {} but the index is {}", move _54, _53) -> bb4; // bb3[34]: scope 4 at x.rs:16:31: 16:35
} The two is correct: let _32: [Foo; 2]; // "f" in scope 2 at x.rs:15:9: 15:10 And it's not affecting downstream MIR optimizations either. Here's the PreTrans MIR diff: diff --git a/working.mir b/broken.mir
index b6ba84c..5d8b34a 100644
--- a/working.mir
+++ b/broken.mir
@@ -213,7 +213,14 @@ fn main() -> () {
// <E2><94><94> span: x.rs:16:33: 16:34
// <E2><94><94> ty: usize
// <E2><94><94> literal: const 0usize
- _36 = Len(_19); // bb3[32]: scope 4 at x.rs:16:31: 16:35
+ _36 = const 2usize; // bb3[32]: scope 4 at x.rs:16:31: 16:35
_37 = Lt(_35, _36); // bb3[33]: scope 4 at x.rs:16:31: 16:35
assert(move _37, "index out of bounds: the len is {} but the index is {}", move _36, _35) -> bb4; // bb3[34]: scope 4 at x.rs:16:31: 16:35
} Attached the tail.txt of the trans log. I don't know how this is breaking anything. |
Ideally this would be moved to the group above itsef (that does nothing): rust/src/librustc_trans/mir/analyze.rs Line 194 in edbd7d2
That way This isn't triggered because the final type is rust/src/librustc_trans/mir/operand.rs Lines 287 to 293 in edbd7d2
It could maybe be moved in the recursive function (assuming this doesn't cost us much). |
Could you try to get this fixed before beta? |
I don't think |
Minimal repro with pub enum Void {}
pub fn foo(xs: [(Void, u32); 1]) -> u32 { xs[0].1 } EDIT: and without #![feature(slice_patterns)]
pub enum Void {}
pub fn foo([(_, x)]: [(Void, u32); 1]) -> u32 { x } This still requires nightly (because of the feature-gated patterns). |
rustc_trans: support ZST indexing involving uninhabited types. Fixes #46855 in a minimal way. I decided against supporting non-memory `Rvalue::Len` in this PR (see #46855 (comment)), as `PlaceContext::Inspect` is also used for `Rvalue::Discriminant`. r? @arielb1
The following code, extracted from #46845, causes an ICE on the 11-27 nightly ("rust 1.23.0-nightly (827cb0d 2017-11-26)") but does not error on the 11-26 nightly ("rust 1.23.0-nightly (e97ba83 2017-11-25)"):
This only triggers when
mir-opt-level
is at least 1. Since it is the only commit in between the nightlies that seems to modify the MIR or have anything to do with MIR optimization, #46264 would seem to be the culprit, but I have no idea why it would cause this and it seems completely valid - it may have just triggered a bug in a different optimization.The error produced (on the latest nightly, which seems consistent with older nightlies) is:
cc @scottmcm, the author of #46264.
The text was updated successfully, but these errors were encountered: