Prevent coercions from polluting the fulfillment context

[arielb1]

This adds transaction support to fulfill. I can't use it in #26282
because that would require nested transactions.

This doesn't seem to cause compilation time to regress.

Fixes #24819.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[arielb1]

r? @nikomatsakis

[bors]

☔️ The latest upstream changes (presumably #26326) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

So, now that the fulfillment context has moved into the inference context, I'd like to integrate it fully into the transactional mechanism there. Sounds like you have a similar ambition. There are other changes I'd like to make -- for example, to track more fully the "parentage" of implications so that we can handle the global caching in a better way, and give better error reports -- and I have the feeling a complete rewrite is in order.

I am torn between saying let's just do the "Right Thing" and landing this PR in the interim. I don't like adding another variant on commit and so forth, but closing an ICE is always nice. So I guess I'm mostly happy to r+ but I'd like to move sooner rather than later on a more full rewrite. (Happy to talk about what that entails on IRC.)

cc @jroesch

[Gankro]

Any progress on the decision?

[steveklabnik]

Triage ping. Looks like this isn't going anywhere, should it be closed? Or did some sort of decision happen?

[arielb1]

@steveklabnik

@jroesch is working on a replacement for this patch.

[nikomatsakis]

going to close in favor of @jroesch's anticipated PR, thanks @arielb1

[jroesch]

@nikomatsakis sounds good, should be soon finally settled in (and have importantly have internet).