fix: Always coerce in a cast, even when there are unknown types

[ChayimFriedman2]

This cause the relationships between inference vars to get recorded.

I'm not entirely sure this is the correct thing to do, rustc's cast handling seems much more complicated, but it seems better than the status quo. CC @ShoyuVanilla I think you've inspected the rustc implementation in the past with greater scrutiny.

Fixes #20644. This issue is unfortunate: when mapping next solver consts to Chalk, Chalk stores the types of the const but the next solver does not, so we stub them with TyKind::Error. Unfortunately, that makes Chalk to mark the type as containing errors. I don't see a way around this, we'll probably need to live with spurious error flags in our types for the time being.

[ShoyuVanilla]

Fixes #20644. This issue is unfortunate: when mapping next solver consts to Chalk, Chalk stores the types of the const but the next solver does not, so we stub them with TyKind::Error. Unfortunately, that makes Chalk to mark the type as containing errors. I don't see a way around this, we'll probably need to live with spurious error flags in our types for the time being.

Could this be mitigated once we become free of chalk completely?

[ChayimFriedman2]

Yes, of course it will ("for the time being").

[ShoyuVanilla]

I've ported most of the cast implementation details from rustc but unfortunately due to our limitations on type inferences like structural sizedness or trait object frustrations (we might be able to deal with some of them by now with next-solver) it caused false-positive cast errors. Those short circuits that returns Ok on error containing types are purely rust-analyzer's quirk to prevent those false positives.

So, trying coercion before them seems not problematic to me. I just have put it after them to prevent unnecessary calculation but if it could propagate relations between ivs that would be good in general

[lnicola]

changelog fixup #20329