fix: prevent infinity evaluate predicate for auto-trait

[bvanjoi]

Fixes #105231

In #105231, an infinity function call occurred when evaluating B<u8> as Send, and the stack was B<u8> -> A<A<u8> -> B<A<u8> -> A<A<A<u8>>> -> xxxx. Although the recursion limit was reached, the error was not emitted directly because #102890 had discarded the cycle_delay_bug, instead, it returned an Error finally, and the panic occurred at expect.

To address this issue, I added a size check before the predicate. If the struct size is infinite, the AutoImplCandidate will not be appended to candidates.

[rustbot]

r? @TaKO8Ki

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

[compiler-errors]

I don't think this is the right approach... I'm going to look into why this ICE occurs, since it seems pretty delicate to fix.

[compiler-errors]

This still breaks if you changed the definitions from:

struct A<T>(B<T>);
//~^ ERROR: recursive types `A` and `B` have infinite size
struct B<T>(A<A<T>>);

to

struct A<T>(B<T>, ());
//~^ ERROR: recursive types `A` and `B` have infinite size
struct B<T>(A<A<T>>, ());

[bvanjoi]

I just tried it and there seems to be no panic here?

[compiler-errors]

Nevermind, I've misinterpreted why you're using sized_constraint here.

Checking that sized_constraint matches [ty::Error] doesn't seem like the right way to check that the struct is cyclical, and after that, not registering an AutoImplCandidate if a type is cyclical also seems like the wrong way to avoid an overflow in the solver.

The correct solution is probably to not ICE on the overflow at all, and instead treat it as ambiguity, but that is (as I said above) a bit delicate...

[bvanjoi]

The correct solution is probably to not ICE on the overflow at all, and instead treat it as ambiguity

Haha, this is a method I never thought of, because when I look at this part of the code, it seems to be all set up for throwing an error after an overflow.

not registering an AutoImplCandidate if a type is cyclical also seems like the wrong way to avoid an overflow in the solver.

can we write it like this:

 if ty.len() == 1 && matches!(ty[0].kind(), ty::Error(_)) {
    make_overflow_error()                       
 }
candidates.vec.push(AutoImplCandidate)

It should eventually throw the following error:

[compiler-errors]

I don't think it's okay to be emitting an overflow error there. Typically we avoid emitting errors from within the trait solver itself (except for pretty specific cases).

[bvanjoi]

If we make the following changes:

struct A<T>(B<T>);
struct B<T>(A<T>);

it will not cause a panic because the code has been checked for cycles in the check_evaluation_cycle function (see here).
Therefore, could we add a similar function called check_evaluation_overflow to check if the current stack has an infinite evaluation process?

[compiler-errors]

I don't think that that's right either. I think we should probably just make predicate_may_hold_fatal not actually ICE. But then there's only one callsite for predicate_may_hold_fatal anyways, so it's probably best to just inline it and delay a bug if we have overflow.

[compiler-errors]

Closing this in favor of the other PR.