Change:
<ins> // MIR for `foo` 0 mir_map fn foo(_1: Box<[T]>) -> T { debug it => _1;                      // in scope 0 at $DIR/issue-91633.rs:+0:19: +0:21 let mut _0: T;                       // return place in scope 0 at $DIR/issue-91633.rs:+0:36: +0:37 let _2: T;                           // in scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 let mut _3: &T;                      // in scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 let _4: usize;                       // in scope 0 at $DIR/issue-91633.rs:+2:17: +2:18 let mut _5: usize;                   // in scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 let mut _6: bool;                    // in scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 scope 1 { debug f => _2;                   // in scope 1 at $DIR/issue-91633.rs:+2:10: +2:11 } bb0: { StorageLive(_2);                 // scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 StorageLive(_3);                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 StorageLive(_4);                 // scope 0 at $DIR/issue-91633.rs:+2:17: +2:18 _4 = const 0_usize;              // scope 0 at $DIR/issue-91633.rs:+2:17: +2:18 _5 = Len((*_1));                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 _6 = Lt(_4, _5);                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 assert(move _6, "index out of bounds: the length is {} but the index is {}", move _5, _4) -> [success: bb1, unwind: bb5]; // scope 0 at $DIR/issue-91633.rs:+2:14: +2:19 } bb1: { _3 = &(*_1)[_4];                 // scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 _2 = <T as Clone>::clone(move _3) -> [return: bb2, unwind: bb5]; // scope 0 at $DIR/issue-91633.rs:+2:14: +2:27 // mir::Constant // + span: $DIR/issue-91633.rs:28:20: 28:25 // + literal: Const { ty: for<'r> fn(&'r T) -> T {<T as Clone>::clone}, val: Value(<ZST>) } } bb2: { StorageDead(_3);                 // scope 0 at $DIR/issue-91633.rs:+2:26: +2:27 FakeRead(ForLet(None), _2);      // scope 0 at $DIR/issue-91633.rs:+2:10: +2:11 StorageDead(_4);                 // scope 0 at $DIR/issue-91633.rs:+2:27: +2:28 _0 = move _2;                    // scope 1 at $DIR/issue-91633.rs:+3:6: +3:7 drop(_2) -> [return: bb3, unwind: bb5]; // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 } bb3: { StorageDead(_2);                 // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 drop(_1) -> [return: bb4, unwind: bb6]; // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 } bb4: { return;                          // scope 0 at $DIR/issue-91633.rs:+4:3: +4:3 } bb5 (cleanup): { drop(_1) -> bb6;                 // scope 0 at $DIR/issue-91633.rs:+4:2: +4:3 } bb6 (cleanup): { resume;                          // scope 0 at $DIR/issue-91633.rs:+0:1: +4:3 } } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Minimized a bit more:
It started ICE-ing in 1.41.0:
This compiles successfully without the bound. It also compiles if you change the bound to constrain the associated type:
I bisected it to be between and : I've tried to bisect between these commits, but I'm getting a compilation error in llvm.
It'll be , which changed the coherence rules to allow . The impl in this code is intentionally allowed under the new rules and should be fine, so it didn't really regress in that PR so much as it was newly permitted but likely surfaced a pre-existing bug. I tried to replicate this issue with a local trait but compiles successfully, so this does seem to involve the built-in trait and operator (the error message complains about the MIR statement which is a built-in index).
Further reduced to: , but not on 1.24.0 I agree with assessment:
So it could be considered a stable-to-stable regression? I don't how or who could add this label.
Yeah, I guess we could modify labels +regression-from-stable-to-stable although it's a regression from a very old stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium