Change:
<ins> error[E0277]: expected a `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)>` --> $DIR/issue-59494.rs:21:22 | LL | fn t8n<A, B, C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) -> impl Fn(A) -> (B, C) |                                             ---------- required by this bound in `t8n` ... LL |     let t8 = t8n(t7, t7p(f, g)); |                      ^^^^^^^^^ expected an `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)>` | = help: the trait `Fn<(_,)>` is not implemented for `impl Fn<(((_, _), _),)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </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<pthe backtrace itself is all </p</details
It's strange, I tried these code in main and it complains about (Compile Error but not ICE) I think the trait is depends on and dyn could resolve this.
Assigning and removing nomination. This was . This one also sounds a bit similar to and which is very old. Would be nice to find if there are duplicates too.
Pinging cleanup to find duplicates ... ping cleanup
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
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .