consider spread tuples when matching signature

[KiaraGrouwstra]

Fixes #4130.

Edit: fixed error on other test. Looks like test results improved there as well.

[Igorbek]

This is really awesome. I think all these error message changes make them more informative.

[KiaraGrouwstra]

Thanks! 😃
Felt like this one worked out without many bumps, yeah.
Wish that were the case for the bigger ones haha.

[MartinMuzatko]

please merge this!

[briantanner]

I'm stuck without this!

[eknowles]

should all those tests have been committed?

[KiaraGrouwstra]

@eknowles: yeah, that was intended; if I hadn't committed the test changes, CI would have errored out on unexpected changes. fortunately the changes themselves seem positive.

[sandersn]

I think we should actually update resolveCall to understand spread tuple arguments instead of rewriting to a series of element accesses. The compiler doesn't expect rewrites of the AST inside the checker, and there's no infrastructure for doing it right either.

I poked at this last month but found it was non-trivial. I'm going to try again and see if I can get a limited version working at least.

[KiaraGrouwstra]

@sandersn: thank you for your take on this, I much appreciate it.
I hadn't really looked into that option, but in retrospect, I think you're right about the AST rewrites...

Although over here I hadn't directly bumped into issues yet, I'd tried this route in my shot at type calls (6606) as well, where the consequences of AST manipulation became all too evident.

I may definitely have been naive in my approach, and I'd be interested to see what a proper approach would end up looking like here. But yeah, I'll take your word for it it wouldn't be trivial...

[sandersn]

@tycho01 I put a prototype up at the branch spread-tuples. It's pretty undone: it duplicates code, doesn't handle complex cases [1], and doesn't allow spread tuples to precede non-spread arguments.

[1] Specifically, overloads and functions with type parameters.

[KiaraGrouwstra]

@sandersn: thanks, I just checked it too. It does look tough having to handle several cases separately rather than being able to just hook into existing logic.

To throw this out there, had the idea of using synthetic nodes been discussed before? I won't deny it feels hacky, though it also helped simplify a few things.

For reference, pain points I experienced with the approach, particularly in #17961, revolved around error reporting / matching nodes as used in the tooltip messages.

I'd definitely only managed to address part of the issues there, but then again, my knowledge about the compiler is still kinda limited anyway.

[typescript-bot]

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.