Simplify arity errors, rewording spread errors

[sandersn]

Arity errors can produce some really strange messages. When I went back and re-learned the arity error rules, I decided the biggest problem is that spread errors are actually a special case, different from other arity errors: spreads of non-tuples are only allowed when the target parameter is a rest:

declare function fn(x, ...args)
fn(...[1,2,3]) // error
fn(1, ...[2,3]) // ok

This is true regardless of type (module having a tuple type, eg [1,2,3] as const), which is why I didn't annotate any in the example above.

Previously, the error message for a mismatched spread was similar to the normal error: "Expected 2 arguments, but got at least n." This didn't indicate the true problem at all. Add to this that n was wrong for calls with multiple spreads, and that the error span was wrong too. It used the span for "too many arguments", which is nonsensical.

This PR:

• Issues a new error message for disallowed spreads.
• Doesn't mention any parameter counts, since they're not relevant.
• Uses the spread as the error span.
• Does not attempt to add new call resolution rules for non-tuple spreads. (I have a couple of ideas here, but I'm not sure how widely applicable or feasible they are.)

It also restructures almost all the code in getArgumentArityError and renames most variables. The function had become baroque even for its previous requirements, but simplifying the spread error message allows it to read in a much straighter line than before. I'd recommend viewing this in side-by-side diff view on a wide-ish monitor.

Fixes #42891
Fixes #28010
Addresses #42508 but does not fix it. I added its test case for this PR.

I'm going to experiment with adding non-tuple spread call resolution rules next.

[sandersn]

@amcasey @andrewbranch I added you to the review because you usually care about error messages, and because you were involved in the precipitating bugs. You don't necessarily need to review the code, but of course you are welcome.

[DanielRosenwasser]

A spread must either have a tuple type or be passed to a rest parameter.

So this is true today - however, I can totally imagine a future where the following could be allowed:

function foo<T extends [string, number, boolean]>(stuff: T) {
    bar(...stuff)
}

function bar(x: string, y: number, z: boolean) {
}

and so I guess the core of this change depends on us always rejecting this code.

[sandersn]

The core of this change is to stop reporting confusing param/arg indices where we should be reporting an arbitrary limitation on spreads. I'm not sure I've explained that limitation well in the error. And the explanation may need to change if the limitation loosens in the future.

[sandersn]

@typescript-bot run dt

(Unrelated to this PR, I want to see if my DT on-demand fix worked)

[typescript-bot]

Heya @sandersn, I've started to run the parallelized Definitely Typed test suite on this PR at 8a265fb. You can monitor the build here.

[andrewbranch]

Addresses #42508 but does not fix it. I added its test case for this PR.

I'm going to experiment with adding non-tuple spread call resolution rules next.

To clarify, are you saying that #42508 should be a wontfix / design limitation, or are you saying you still hope to fix it soon, but in a separate PR?

[sandersn]

I hope to fix #42508 soon. I'm going to try treating [number, number] | [number, number, number] like [number, number, number?] but it may not work out. I don't expect any fix I make there to generalise to all non-tuple spreads.

[andrewbranch]

I think this closes #28010 since the decision was just to clean up the nonsense error, which this does.

[amcasey]

And the explanation may need to change if the limitation loosens in the future.

It would be easy to forget to update this resource string, so it would be nice if we could come up with text that would continue to work if Daniel's plausible change is made.

Otherwise, seems sensible. I only skimmed the product changes.

[sandersn]

I'll line up a time to talk with @DanielRosenwasser and see if we can come up with a message that is forward-compatible, although I think the current state is already close to fit for that purpose.

[sandersn]

A draft of a couple more expansions for spread arguments is up at #43882. However, after implementing the prototype, I'm even less confident that they're correct.