Change:
let result = tcx.normalize_projection_ty(c_data)?; // We don't expect ambiguity. if result.is_ambiguous() { <del> bug!("unexpected ambiguity: {:?} {:?}", c_data, result); </del> <ins> // Rustdoc normalizes possibly not well-formed types, so only // treat this as a bug if we're not in rustdoc. if !tcx.sess.opts.actually_rustdoc { tcx.sess.delay_span_bug( DUMMY_SP, format!("unexpected ambiguity: {:?} {:?}", c_data, result), ); } return Err(NoSolution); </ins> } let InferOk { value: result, obligations } = self.infcx.instantiate_query_response_and_region_obligations(

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm Rust newbie and I try to make a microservice. The offending line was at first the following: function serve When I did "cargo check", I had an error and when I tried to correct it with the recommended option, I panic message. I will investigate further to simplify the code, and sends this as requested in the error message. Regards Didier
Hi, thank you for your report. Can you verify that this issue still occurs on the latest nightly version?
Hi Nilstrieb, yes, same behavior with the nightly build.
This check was promoted to 'internal compiler error' in commit as part of pull request (
Looks like this is the same issue as , which unfortunately also doesn't contain useful info.
Thank you for the info. Best regards Didier
I can look into this. I was investigating the same assertion in . claim
Minimized quite a lot:
Hello. Michael, Many thanks, I will look at it and for sure learn a lot more Regards Didier Rigoli Senior Manager
This regressed in -- I can't really work on it any further without a self-contained, minimized version of the ICE, which I attempted and failed to do. If someone wants to minimize it, then that would be greatly appreciated, and I can pick it up after that if nobody else has. ping icebreakers-cleanup-crew release-assignment
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
Minimized more (): <details<summary<strongError output</strong</summary<p</p</details
How could an ambiguity error be raised when the canonical request has no inference variables? This looks interesting.
It's related to the variable name resolution error being emitted earlier, so maybe the inference context being tainted by errors causes something about evaluation to get messed up.
Here's a cve without any external dependencies. Not quiet small, but it does the job.
Minimized: label S-bug-has-mcve
interesting enough you seem to trigger the ICE in a different way than me? You're using the token, I use an incomplete trait impl. Maybe it's worth to test a possible solution to both inputs?
I'm pretty sure I understand this error now. Either via solution of having a with an error in its body, or via solution of having a missing associated type , we end up trying to check a trait bound on a () type in order to normalize a type inside a closure signature, which ends up evaluating as ambiguous. However, we don't handle ambiguities properly with the normalization query call. I took a stab at fixing this in , and I extended it a bit to also fix these cases, too.