A few fixes for associated types

[arielb1]

Fixes #25700

r? @nikomatsakis

[nikomatsakis]

So, some thoughts:

First, I think trans shouldn't encounter this path, since we always know what trait a closure implements, but I could be wrong -- perhaps it encounter ambiguity in some other way? Presumably something is missing in this explanation, because (according to you) normalization is not needed during typeck and (according to me) this path doesn't matter during trans, but that would imply that this fix doesn't fix anything, right?

Second, I think we could make the code more robust in two ways:

1. refusing to normalize if the result creates obligations that must be resolved (seems like an arbitrary limitation, but if this path is really only important to trans, perhaps it's enough to just "not act" until such time as enough progress has been made to resolve the ambiguity)
2. extending the inferface to allow those obligations to be propagated back

(Longer term, as I keep mentioning, I think I'd like to move to a lazy normalization scheme.)

[arielb1]

@nikomatsakis

Actually, we probably can't really encounter this during trans (because there is no potential ambiguous impl for ty_closure: Fn*).

[nikomatsakis]

@arielb1 ok that's what I thought. Are you going to push an updated version with two fns, as we discussed in IRC? (If so, please do ping me when it's ready...)

[nikomatsakis]

@bors r+ -- this looks nice. thanks for iterating with me.

[bors]

📌 Commit 21fd312 has been approved by nikomatsakis

[bors]

⌛ Testing commit 21fd312 with merge ff8fee1...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt