Integer type variable gets lost during trait solving

[flodiebold]

Somehow in the first case, the type variable seems to get 'disconnected' in the chain, whereas it works for a concrete type or a normal type variable 🤔

[adamrk]

I'm not seeing the this issue, but I do see the one from #4132 (on commit 9230ae5):

[flodiebold]

The original problem indeed seems to have fixed itself, which is interesting -- I have no idea what might have done that.

The problem with ranges is a variation of rust-lang/chalk#327, I think: Since we haven't fallen back to i32 yet when we're checking the from_iter call, we basically ask Chalk "does Range<?0> implement Iterator, and what's the type of Iterator::Item?" The problem is, Range<T> only implements Iterator for T: Step. So the answer from Chalk is "maybe, but no idea what the item type is", because it doesn't know that the impl applies. Whereas rustc can see here that because ?0 has to be some kind of integer, regardless of which one it is, it'll implement Step and so the impl<A: Step> Iterator for Range<A> applies. At least, I think that's how rustc figures it out. (Alternatively, maybe it just reasons that that impl is the only one that could apply anyway, so at least the item type has to be ?0. I.e. Chalk could be better at giving guidance even if the result is ambiguous.)

Edit: Actually yeah, it's the second option, since rustc also figures it out when the type variable is a general type variable.

[JohnWall2016]

There're some same problems about the range literals: