Avoid infinite cycle in coerce_unsized_old_solver when encountering invalid recursive struct definition

[estebank]

If an obligation's nested obligations expands to itself, do not add it to the working queue.

Fix #148653.

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[estebank]

There might be a better approach.

CC @lcnr

[BoxyUwU]

r? lcnr

i don't have the capacity to properly investigate the custom unsizing solver logic rn

[lcnr]

this feels really brittle

I don't fully understand what's necessary for this to diverge, but would expect it to be possible to have non-trivial recursion here as well, e.g. why does the following not have issues

struct Vec<T> { //~ ERROR recursive type `Vec` has infinite size
    data: Vec<Vec<T>>, //~ ERROR type parameter `T` is only used recursively
}
impl<T> Vec<T> {
    pub fn push(&mut self) -> &mut Self {
        self
    }
}

I feel like we probably should properly increment the recursion_depth of the obligations and have a recursion limit check here instead

[lcnr]

alternatively this might cause issues if they reference different regions (or we just don't resolve them to be equal at that point). relying on structural equality for diversion checks is just really brittle 😅

[estebank]

I don't disagree, I just tried to make the minimal possible patch (that I could find in a limited amount of time) that could avoid the hang on the current solver.