I tried reverting the order of source/target on parameters to recover the lost error elaborations. Unfortunately, that introduces a bug in which for the following:

function foo<T extends "foo">(f: (x: T) => T) {
    return f;
}

let f = foo((y: "foo" | "bar") => y === "foo" ? y : "foo")

We report

    let f = foo((y: "foo" | "bar") => y === "foo" ? y : "foo");
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!!! error TS2345: Argument of type '(y: "foo" | "bar") => string' is not assignable to parameter of type '(x: "foo") => "foo"'.
!!! error TS2345:   Type 'string' is not assignable to type '"foo"'.
!!! error TS2345:     Type '"foo" | "bar"' is not assignable to type '"foo"'.
!!! error TS2345:       Type '"bar"' is not assignable to type '"foo"'.

Which is

1. An elaboration of the source parameter type being unassignable to the target one (see the bottom two messages)
2. An elaboration on the source return type being unassignable to that of the target. This is because compareTypes succeeded in assignability of the target parameter type to the source parameter type, and we're still using the same elaboration stack.

I'd rather not introduce a callback to revert the elaboration stack between calls to compareTypes, so I think I'm going to try to find a way to make the current code work.

Hey @sandersn and @JsonFreeman any other feedback? I think I've improved error baselines by elaborating in most cases except for primitives. I've also simplified the code by eliminating that elaborateErrors variable.

Looks good to me. But as I said, I'm sick, so make sure @JsonFreeman or future-me (the not-sick one) okays it too.

Reviewed the error baselines in detail and it's a great improvement. I'm not as familiar with this part of the signature checking code so I'd defer to someone else on that front -- there was nothing obvious wrong about it, though.