Make reproducing test(s) for failing to generalize program clauses

[nathanwhit]

If program clauses are not properly generalized it can cause issues in the recursive solver. This was the cause of the recent breakage in rust-analyzer. We should have a test that covers this to prevent future issues.

Discussed briefly here.

[detrumi]

Minimal example:

fn main() {
    foo(|a: u32| {});
}

fn foo<F>(f: F)
where
    F: Send,
{
}

Trying to fit this in a test is tricky though, as the problem triggers with this goal:

Implemented({closure:ClosureId(0)}<for<0> Safe () [?0 := Uint(U32), ?1 := ^1.0]>: Send)

The syntax has changed slightly since (old debug formatting here), but this is a TyKind::Closure with the substitution being a FnPointer (for<0> Safe () [?0 := Uint(U32), ?1 := ^1.0]).

I don't think there's currently a way to trigger closure substitutions in chalk tests. My attempts so far:

test! {
        program {
            #[lang(fn_once)]
            trait FnOnce<Args> {
                type Output;
            }

            #[auto] trait Send { }

            fn foo<F>(f: F) -> ()
                where F: Send;

            closure bar(self, a: u32) {}
        }

        goal {
            <bar as FnOnce<(foo<(bar, u32)>)>>: Send // Not valid test syntax
        } yields {
            "Unique"
        }
    }

Similar goals like bar: Send or fn(bar): Send don't trigger the problem.

[flodiebold]

Yes, I've had similar problems reproducing problems with closures from RA. Maybe the closure support in the test harness needs to be more flexible somehow. I've usually been able to reproduce the problems by just modeling the closure as a normal struct.