-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow signature help argument count to be equal to argument index #58203
Allow signature help argument count to be equal to argument index #58203
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
if (argumentIndex !== 0) { | ||
Debug.assertLessThan(argumentIndex, argumentCount); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it might look weird that this allows what usually isn't allowed - it all depends on the definition of those values. I think it makes sense to treat them as follows:
- argument index - a min argument index at the position
- argument count - a minimum count of known arguments
A spread element doesn't always increase such an argument count but the argument index at its positions gets increased
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But what should an editor do when the argument index exceeds the count? The index has to be capped, doesn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of bounds indexes are just ignored; on Python I did this intentionally, too (previously used a negative number until some rust-based LSP clients started getting picky). See: microsoft/language-server-protocol#1271
But, I'm more confused by how a spread element would change the number here; we're definitely indexing them correctly left to right, correct? Like if we have (x, {y, z})
, we don't go out of bounds on z
because it's "at index 2" but the number of real params is 2? I assume not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But what should an editor do when the argument index exceeds the count? The index has to be capped, doesn't it?
The added baseline here shows how we can still highlight the parameter in the signature - at least in this case 😉
But, I'm more confused by how a spread element would change the number here
function test(...args: any[]) {}
const twoNums = [2, 3] as const
test(1, ...twoNums)
In the situation above the rest adds 2 to the count (and not 1). See the PR that changed this: #56372
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: That's a spread, not a rest. Rest is what you do when destructuring, spread is what you do at construction ("rest" doesn't make sense in that context because you can have multiple).
@typescript-bot pack this |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
…o-be-the-same-as-index
fixes the issue reported here #58191 (comment)
a regression from #56372 , not fixed by #57637