Change:
if (src, dest).has_opaque_types() { return true; } <del> // Normalize projections and things like that. let param_env = self.param_env.with_reveal_all_normalized(self.tcx); let src = self.tcx.normalize_erasing_regions(param_env, src); let dest = self.tcx.normalize_erasing_regions(param_env, dest); </del> <ins> // Normalize projections and things like that. </ins> // Type-changing assignments can happen when subtyping is used. While // all normal lifetimes are erased, higher-ranked types with their // late-bound lifetimes are still around and can lead to type // differences. So we compare ignoring lifetimes. <del> equal_up_to_regions(self.tcx, param_env, src, dest) </del> <ins> // First, try with reveal_all. This might not work in some cases, as the predicates // can be cleared in reveal_all mode. We try the reveal first anyways as it is used // by some other passes like inlining as well. let param_env = self.param_env.with_reveal_all_normalized(self.tcx); if equal_up_to_regions(self.tcx, param_env, src, dest) { return true; } // If this fails, we can try it without the reveal. equal_up_to_regions(self.tcx, self.param_env, src, dest) </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</detailsThis came from a workaround for what seems to be an old compiler bug. removing the workaround gets ride of the ICE: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you post what your dependencies are? Or include the statements? Ideally with the versions too. Or something that can just be stuck in a that compiles? I'm not sure where the is coming from in the code above (in the struct layout)
Of course, my bad for not providing this upfront. I've been able to repo it with this setup: deps/features:
Ah yes, thank you very much. I can reproduce it (with the feature, so all the other crates can presumably be removed). I'll look into this.
For reference, minimised it down to this: I also bisected this, and it turns out to be the same rollup as in ... So I suspect both these errors were introduced in the same commit. Interesting! Edit: Adjusted the code (edit2: twice!), check comment history for the original.
Here is the MIR for the function when I manually disabled validation (I just noticed, validation doesn't have to be disabled, works anyways)
After looking into this a bit, I got the following: The body is treating the generic type and the concrete associated type to be of the same type. The MIR validator probably thinks that this is very sketchy and bails out (I haven't looked at it closely). This is actually ok though, since in the where bounds is constrained to be equal to . To me, this looks like a bug in the MIR validator.
This was probably regressed by .

cc
Yes, manually reverting the PR fixed the issue for me locally.
While it regressed in that PR, the PR only called validation that wasn't called before. The validation has been broken for longer.
claim
Probably just needs a normalize call somewhere :thinking:
Does not ICE any more after . Test in .
Oooppsss... Sorry, this test still ICE. On the bright side, I was able to reduce the compiler arguments to .