properly decrement available_depth on cycles and provisional cache hits

[sjwang05]

cc https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/overflow.20fcw.20depends.20on.20cached.20results.20with.20cycles/with/625345435

With this change, the fuzzer doesn't seem to catch any mismatches or errors. If we decrement only on a cycle and not on a provisional cache hit, the fuzzer does report some mismatches.

I decided to directly pass available_depth instead of using the lower_available_depth arg since allowed_depth_for_nested already computes available_depth based on lower_available_depth.

r? lcnr

[sjwang05]

If we decrement only on a cycle and not on a provisional cache hit, the fuzzer does report some mismatches.

and here is one such program whose result depends on the provisional cache! :D

#![recursion_limit = "6"]
use std::marker::PhantomData;

// We need to decrement available_depth on provisional cache hits.
// e.g., in the following example:
// A: Send, avail = 6
// -> PhantomData<A>: Send, avail = 5
//    -> A: Send, avail = 4
// -> B: Send, avail = 5
//    -> C: Send, avail = 4
//       -> PhantomData<A>: Send, provisional cache hit, avail = 4 if we don't decrement
struct A(PhantomData<A>, B);
struct B(C);
struct C(PhantomData<A>);
struct W<T>(T);

fn require<T: Send>() {}

fn main() {
    require::<A>();
    require::<W<W<W<W<A>>>>>();
}

I've added both the cycle and provisional cache versions as uitests

[lcnr]

@bors r+ rollup

[rust-bors]

📌 Commit e9824e4 has been approved by lcnr

It is now in the queue for this repository.