TypeScript Bot (@typescript-bot) perf test this

Heya Nathan Shively-Sanders (@sandersn), I've started to run the perf test suite on this PR at 4e3c2c5. You can monitor the build here. It should now contribute to this PR's status checks.

Update: The results are in!

Nathan Shively-Sanders (@sandersn)
The results of the perf run you requested are in!

Comparison Report - master..36665

No impact to check time, but it doesn't mean much without knowing how many overload errors are in the perf test suite. That's the next thing I need to look at.

Hey, it at least means that the hypothesis of "this should only affect compilations with errors" is probably true~

So, uh, here are the numbers of getCandidateForOverloadFailure calls. They are small. The number in parenthesis is the total number of resolveErrorCalls; that function is called a number of places.

I'm still leaning toward yes since it appears (1) to be pay-to-use (2) angular, the project that uses it a little, on the whole checks at the same speed.

Wesley Wigham (@weswigham) if you agree, sign off and you or I can merge this.

Actually, I want to look over the baseline changes before I sign off. So far the look benign, but there are a lot of them.

Note: breaks jest types in the following call:

const spy3Mock = spy3
    .mockImplementation(() => '')
    .mockImplementation()
    // $ExpectError
    .mockImplementation((arg: {}) => arg)
    .mockImplementation((...args: string[]) => args.join(''))
    .mockImplementationOnce(() => '')
    .mockName('name')
    .mockReturnThis()
    .mockReturnValue('value')
    .mockReturnValueOnce('value')
    .mockResolvedValue('value')
    .mockResolvedValueOnce('value')
    .mockRejectedValue('value')
    .mockRejectedValueOnce('value');

The last four calls expect an argument of type never now instead of string. This seems wrong, or at least unintended.

Oh, the tests were ALWAYS an error, it's just the we now report downstream errors after the expected error on mockImplemention((arg: {}) => arg).
If you move the mockResolveValue calls above that line, you get the error even before this change.

The test should be making those calls on a mock of a promise, so that's probably the right fix.

Nathan Shively-Sanders (@sandersn) Somehow this has caused some concerning regressions in rwc (lol we didn't run rwc) to do with elided imports (namely we're failing to mark some imports as used and they're mistakenly elided). I don't think it's a fundamental flaw with this, but it's definitely something we need to look into. The affected projects include Azure_FrameworkTests and immutable. (You can see the diffs on the rwc diff PRs)

The immutable case is something like

//@filename: Traversable.ts
export interface ITraversable<T> {}

export function isTraversable(a: any): boolean {
    return isList(a) || isOption(a);
}

export function isList(a: any) {
    return (a instanceof _list.Cons) || (a instanceof _list.Nil);
}

export function isOption(a: any) {
    return (a instanceof _option.Some) || (a instanceof _option.None);
}
// @filename: List.ts
import _tr = require('./Traversable');
export class Cons<T> extends IList<T> {

    flatten<U>(): IList<U> {
        return this.foldLeft<IList<U>>(new Nil<U>(), (acc, t) => {
            if(_tr.isList(t)) { // usage here
                var l = <IList<U>><any> t;
                return acc.append(l);
            } else if(_tr.isOption(t)) { // and here
                var o = <_option.IOption<U>><any> t;
                if(o.isDefined()) {
                    return acc.appendOne(o.get());
                } else return acc;
            } else {
                return acc.appendOne(<U><any> t);
            }
        });
    }

}

I think we're failing to check a child function body or something?

Probably when there is an error in the parent call expression. I observed this in the user tests too.

Makes sense that we wouldn't have noticed this since our test coverage of the language service is so much worse, and getCandidateForOverloadFailure was only called from there.

After discussion with Wesley Wigham (@weswigham), the fix is to make getCandidateForOverloadFailure call resolveUntypedCall the way resolveErrorCall does. resolveUntypedCall is just a barebones set of check* calls.