Always call getCandidateForOverloadFailure

[Deleted user (ghost)]

This would make it so the command line compiler and services don't differ in the overload chosen.

[Nathan Shively-Sanders (sandersn)]

Wesley Wigham (@weswigham) Should we be worried about performance problems in services from merging this? resolveUntypedCall is way simpler than getCandidateForOverloadFailure. Unfortunately we don't have an easy way to measure perf differences for a PR there.

(Andrew Casey (@amcasey) in case this is a scenario you want to take note of.)

[Wesley Wigham (weswigham)]

Should we be worried about performance problems in services from merging this?

The reverse - you should be concerned that command line performance might suffer; the language service checker has always been using the more expensive getCandidateForOverloadFailure - that's how it still provides completions, even in the presence of errors; unlike the command line compiler, it doesn't immediately replace the result with any.

Since that's the concern, a simple perf test on this PR should bear out if that's really a problem.

[Nathan Shively-Sanders (sandersn)]

Oh, yeah, I misread produceDiagnostics. I'll merge with master and run a perf test then.

[Wesley Wigham (weswigham)]

Do note that this is technically a prerequisite for #28584 (which is probably why you're here), which we'd like to be able to take to reduce services memory usage~

[Nathan Shively-Sanders (sandersn)]

Ha ha nope. I'm just going through Pall Mall by order of age. #28584 is next.

[Nathan Shively-Sanders (sandersn)]

Closing in favour of #36665 since I couldn't find the branch for this PR.

[TypeScript Bot (typescript-bot)]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.