r? @chenyukang

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

This feels like the wrong fix to me. I'm not an EII expert, but isn't the actual problem that EII impl resolution is returning non-fn definitions? The ICE here is helpful in that it caught that bug; we shouldn't be papering over it.

This feels like the wrong fix to me. I'm not an EII expert, but isn't the actual problem that EII impl resolution is returning non-fn definitions? The ICE here is helpful in that it caught that bug; we shouldn't be papering over it.

That said, I don’t think this change is the “wrong” fix for the ICE itself. Right now compare_eii_function_types assumes that the declaration is always a function and calls fn_sig() unconditionally. When that assumption is violated we get an ICE, which is still not acceptable behaviour even if the resolver is buggy. I agree about the root cause: the EII resolver should never return a non‑fn DefId, and Ive already looked into it and tried to fix locally

It's totally fine for functions to ICE when their preconditions are violated; that's better for catching bugs than returning a nice error would be. In this particular case, I don't have the expertise to say whether there's a huge difference between fixing resolution and catching bad resolutions in post. But as a general matter, we shouldn't be changing ICEs to errors when the ICE is indicative of an underlying issue.

It's totally fine for functions to ICE when their preconditions are violated; that's better for catching bugs than returning a nice error would be. In this particular case, I don't have the expertise to say whether there's a huge difference between fixing resolution and catching bad resolutions in post. But as a general matter, we shouldn't be changing ICEs to errors when the ICE is indicative of an underlying issue.

i'm agree with you, i will finish my tests with fixing of the root cause soon and create separate PR, tho experts could check two different solutions of the problem and we could choose from there

In this particular case it might be fine to validate later, since that's what check_eiis is doing. Maybe best to catch before it gets to compare_eii_function_types though. I'll leave it up to Jana.

oops, wrong button

Closing in favor of #152384.