Plumb inference obligations through librustc/middle, take 3/2

[soltanmm]

This is a limited rewrite of #31867 due to its significant bitrot. Due to some recent work on master using Lub across multiple commit_if_oks I plumbed type-relating side-effects through relate.rs instead of using internal state in individual TypeRelation implementors.

There's some miscellaneous clean-up and I'll admit to being lazy about using some old try!s instead of the ? syntax, but IIRC that can be addressed by an automated tool taking a pass at the code again whenever.

Next up: replacing consider_unification_despite_ambiguity with a new obligation variant that's satisfied after a closure type has been determined.

cc @jroesch
r? @nikomatsakis

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[nikomatsakis]

Hmm. Passing the &mut may indeed be a practical way to go about things, though it feels a bit wrong to me somehow. (I'm trying to decide why though; I guess because it seems easy to accidentally mutate the vector and then have an Err result?) I guess that the recent "LUB" changes were done in the inference step? That may be easy to refactor, as well.

Regardless, I'm inclined to land this work in some form, we can always fine tune later.

[soltanmm]

@nikomatsakis The relevant code was under src/librustc_typeck/check/coercion.rs (here). Oddly enough

[...] I guess because it seems easy to accidentally mutate the vector and then have an Err result [...]

was the reason why I changed it up for the code in coercion.rs. Every time a commit_if_ok went through, I'd have needed to check whether or not the collected obligations were from a failure and would need to be cleared, because later on the Lub object could be used again despite failure. With this way one could just change the code to recreate an empty vector each time relate is called (which I'm admittedly not doing at the moment).

I didn't try to figure through whether or not error reporting or whatever other side effects on the inference context depended on keeping e.g. the same trace across failures or other side-effects on the TypeRelation implementor being kept across failures. If it doesn't then the offending code can just reconstruct an Lub everywhere it's relateing instead and the PR can go back to keeping the generated obligations in the TypeRelation implementor.

^{Edited for a wee bit of clarity}

[nikomatsakis]

@soltanmm I totally agree that if we are going to re-use a Lub, then we should not implicitly carry the vector in there. The question is more whether we ought to ensure that Lub is a "one-shot" value.

[nikomatsakis]

@soltanmm and I touched base on IRC and decided to try refactoring the coercion code. Therefore, going to close this PR pending his revisions. Thanks @soltanmm !