-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Add support for completions inside string literals #8428
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
Changes from 1 commit
21587aa
0a277a1
060f2a8
7b0d664
4464a41
291ad33
e5a32b7
02f30ff
b9ab4d3
f657e3c
9027da4
cc5dd5b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4164,12 +4164,15 @@ namespace ts { | |
|
|
||
| const argumentInfo = SignatureHelp.getContainingArgumentInfo(node, position, sourceFile); | ||
| if (argumentInfo) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor: could you add comments from the PR description here. so we know what cases are covered
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sure. |
||
| // Get string literal completions from specialized signatures of the target | ||
| return getStringLiteralCompletionEntriesFromCallExpression(argumentInfo); | ||
| } | ||
| else if (isElementAccessExpression(node.parent) && node.parent.argumentExpression === node) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why you have to check this "node.parent.argumentExpression === node"?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
| // Get all names of properties on the expression | ||
| return getStringLiteralCompletionEntriesFromElementAccess(node.parent); | ||
| } | ||
| else { | ||
| // Otherwise, get the completions from the contextual type if one exists | ||
| return getStringLiteralCompletionEntriesFromContextualType(<StringLiteral>node); | ||
| } | ||
| } | ||
|
|
||
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.
This seems like a slightly weird sort of dependency. Ideally there would be an API on the type checker like
getPossibleContextualTypesThere 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.
this is not contextual type per se. but sure. If there is another use case for such API we can push it into the checker, but this is the only one, i would keep it at the use site.