Always call getCandidateForOverloadFailure

[ghost]

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

[sandersn]

@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.

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

[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.

[sandersn]

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

[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~

[sandersn]

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

[sandersn]

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