Change:
<ins> error[E0277]: the trait bound `dyn Foo: CastTo<[i32]>` is not satisfied --> $DIR/issue-71659.rs:30:15 | LL |     let x = x.cast::<[i32]>(); |               ^^^^ the trait `CastTo<[i32]>` is not implemented for `dyn Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Found in the crater run: ICEs: This ICE happens on: but rustc builds fine.
Is this going out in the new stable?
Oh, this crate is full of unstable features, so no need to worry about stable
Then I guess it would be worth minimizing this to check that we're unable to reproduce this with no unstable features, and if we can't, it would still be good to have a test case for the "culprit feature".
I got it down to this, I haven't been able to remove so I think short term it's fine.
ping cleanup-crew I've tried roughly bisecting some nightlies, it starts somewhere between 2020-06-09...2020-07-09.
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I'm not sure why I didn't bisect this as I'm all set up to do it..... the regression was in nightly 2020-06-22, specifically somewhere in this rollup:
possibly , cc
Assigning given this as and removing .
Triage: This () is no longer ICE with the latest nightly, it'd be great if someone could confirm whether the original is also fixed, marking as E-needs-test for now. EDIT: Confirmed that the original issue is also resolved, it's just compiled fine on my local.

<!-- 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
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

() Errors: Removing the makes this generate appropriate error messages. Seems like combining and is rather uncommon, at least there are no other issues with both labels yet. modify labels: I-ICE, T-compiler, requires-nightly, F-associatedtypedefaults, F-genericassociatedtypes, A-traits, A-associated-items, C-bug
Okay, this bug allows you to do basically everything. For example () () arbitrary transmutes (as long as LLVM doesn’t complain like it did above) ()
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'fy labels:' '"I-unsound'... Please let know if you're having trouble with this bot.
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Here's another one ICE's with:
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.
Looks like this was the fix:

If a trait has two or more subtraits, and one obtains a reference to something that implements that trait under specific conditions, typeck reports an error for indexing with all but the last 's key. Seems to happen only if that reference was obtained through another trait's output type. Consider the following example (): This breaks with the message: The issue does not occur if the indexing is performed on a directly. That is, the following works just fine (): What I would expect to happen is that all three index operations work. More specifically, I would expect each of the operations to produce the corresponding type correctly. :
The problem also occurs if is called explicitly (): Or also when is called explicitly (): However, the problem does not occur if the key type is specified together with the trait ():
modify labels to A-traits, A-associated-items, A-inference, C-bug, and T-compiler.
Feels like a duplicate of
This is fixed on nightly. Presumably by
Bisection points to , so it is indeed. I guess we still need modify labels to E-needs-test.

ICE whilst experimenting with opaque/existential types. I tried this code: I expected to see this happen: in stdout Instead, this happened: ICE! : Backtrace: (The above backtrace but with )
I can still reproduce the issue after a , new output of :
Not completely sure, but I think this might be another example of this ICE ():
I've looked into this a little bit - I don't know what the correct behavior is, but hopefully this saves someone some time when they go to fix this (or someone can tell me what the correct behavior is and I can fix it). The following assumes the test case from . This error is emitted during MIR type-check here: It happens when the isn't in in . is to during typeck writeback, here: In particular, this case is when we're considering the for , where has two values - and . For , we end up infering the concrete type to be and fall into this branch: This code exists to avoid considering a defining use in this example: gets those values here from , which is returned from : That ends up at here: This looks over the type (in this case, the return type, , of , whose definition is ) and looks for the opaque types, and creates inference variables for their concrete types. As a result of this, is effectively considered a defining use for both and . is inferred to be - trivially, because of the return value of . Because is used in the type of , whatever type that ends up being will be considered a defining use of too - and the impl of for (what is) says that should be - so 's concrete type is considered to be . That triggers the logic in writeback where we skip adding the concrete type to - and hence the ICE in MIR type check. As I see it, there are two possible options here: 't consider a defining use in this case (when the use in the return type is in a bound), so the concrete type will come from the other defining uses. that the inference variable that ends up being doesn't come from a defining use (but from the trait implementation) and so should be ignored or an error emitted.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.