There used to be only a global cache, which led to uncached calls to
trait selection when there were type parameters.
I'm running a check that there are no adverse performance effects.
Fixes#37106 (drop elaboration times are now ~half of borrow checking,
so might still be worthy of optimization, but not critical).
This commit avoids the `resolve_type_vars_if_possible` call in
`plug_leaks` when `skol_map` is empty, which is the common case. It also
changes the signature of `plug_leaks` slightly to avoid the need for a
`clone` of `value`. These changes give speed-ups of up a few percent on
some of the rustc-benchmarks.
This flag is a debugging measure designed to detect cases where we start
a snapshot, create type variables, register obligations involving those
type variables in the fulfillment cx, and then have to unroll the
snapshot, leaving "dangling type variables" behind. HOWEVER, in some
cases the flag is wrong. In particular, we sometimes create a
"mini-fulfilment-cx" in which we enroll obligations. As long as this
fulfillment cx is fully drained before we return, this is not a problem,
as there won't be any escaping obligations in the main cx. So we add a
fn to save/restore the flag.
Cache projections in trans
This introduces a cache for the results of projection and normalization in trans. This is in addition to the existing cache that is per-inference-context. Trans is an easy place to put the cache because we are guaranteed not to have type parameters and also we don't expect any failures or inference variables, so there is no need to cache or follow-up on obligations that come along with. (As evidenced by the fact that this particular code would panic if any error occurred.)
That said, I am not sure this is 100% the best place for it; I sort of wanted a cache like we have in the fulfillment context for global names; but that cache only triggers when all subsequent obligations are satisfied, and since projections don't have an entry in the obligation jungle there is no easy place to put it. I considered caching both the result and obligations globally, but haven't really tried implementing it. It might be a good next step.
Regardless, this cache seems to have no real effect on bootstrap time (maybe a slight improvement), but on [the futures.rs test case I was looking at](https://github.com/rust-lang-nursery/rustc-benchmarks/pull/6), it improves performance quite a bit:
| phase | before | after |
| ----- | ------ | ----- |
| collection | 0.79s | 0.46s |
| translation | 6.8s | 3.2s |
| total | 11.92s | 7.15s |
r? @arielb1
There were various places that we are invoking `drain_fulfillment_cx`
with a "result" of `()`. This is kind of pointless, since it amounts to
just a call to `select_all_or_error` along with some extra overhead.
E0072 update error format
Part of #35233Fixes#35506
r? @jonathandturner
The bonus for this issue currently seems to be impossible to do reliably, as the compiler seems to lack span information for item names alone, like `Foo` in `struct Foo { ... }`. It would be possible to hack something together by computing span offsets, but that seems like a solution that would be begging for trouble.
A proper solution to this would, of course, be to add span information to the right place (seems to be `rustc::hir::Item::name` but I may be wrong).
The type equation in projection takes place under a binder and a snapshot, which
we can't easily take types out of. Instead, when encountering a projection error,
try to re-do the projection and find the type error then.
This fails to produce a sane type error when the failure was a "leak_check" failure.
I can't think of a sane way to show *these*, so I just left them use the old crappy
representation, and added a test to make sure we don't break them.
