Change:
let (&normalized_output_ty, normalized_input_tys) = normalized_inputs_and_output.split_last().unwrap(); <ins> debug!(?normalized_output_ty); debug!(?normalized_input_tys); </ins> let mir_def_id = body.source.def_id().expect_local(); // If the user explicitly annotated the input types, extract

Discussion:
This is related to and ; but is not the same issue: is already resolved and is dealing with a more complex case where inference is lacking. Also perhaps related to I'm filing an ICE because that's what I'm hitting as I try to reduce it, however I have a related bug where the workaround from doesn't actually work. I wonder if fixing the ICE will make this code compile or if it will hit code that needs to be worked around (My unreduced code is at , ) <details<summaryCode </summary<!-- 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. --: </details <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc
Probably related to
I've looked into this: The problem here is that we try to the normalized (coming from and being normalized ) with the unnormalized closure type from the . The normalized input ty in this example corresponds to a closure with substs: and the unnormalized input ty from the mir is a closure with substs: . This fails since the output types cannot be equalized. We can make this compile by normalizing  (note that we cannot normalize the for the closure during typecheck since this leads to other type relation problems), but I feel that this misses the actual problem. I would expect that we would get problems when actually building this if some associated type in the mir is not normalized. Can you give me an example including a main function that uses upcast? I had problems fulfilling the bound when supplying an argument to .
Wait I'm a bit the hack that I literally right there not work?
Yes, that fails to normalize it.
Ah, I see, it's that is unnormalized. Can we just repeat the hack to normalize ? As you stated (and I found previously), this does miss the problem, but it's a difficult problem to solve.
trying to write the upcast displays the related bug that I was trying to reduce in the first place: which throws As mentioned before, this is along the same vein as and : The trait bound is satisfied by the type, rustc just can't figure it out.
No 'b' is unnormalized, the problem seems to be that an empty is passed to .

I can open a PR for that. One question though, when we normalize we add region constraints by using , can we ignore these constraints here?
Ah I see; I was reading it as the first arg. So, In , the first fails, so we try to normalize . Now, specifically, we need to normalize to . The question is why. We shouldn't need the here. The problem might be related to the fact that the impl is implemented for the lifetime whereas this looks like some inference region var (but that should just come out as region constraints which we maybe should ignore). We should be able to, yes.
You're right about the second projection, but the normalization of actually fails because cannot be normalized and we need the for that.
Oh are we only able to normalize "all or nothing"? I'm not worried about that because it also appears in
yeah its not important for the eq relation here, but returns an error because isn't provable if we don't supply the correct param_env.
The ICE is now fixed, but the underlying bug I was trying to reduce still exists, going to file another issue.

I tried : This should compile and work, but instead it ICEs. It doesn't ICE if I remove the generic parameter from or use <!-- 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<summaryBacktrace</summary<p</p</details
Seems related to