Skip to content
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

Add support for completions inside string literals #8428

Merged
merged 12 commits into from
Jun 8, 2016

Conversation

mhegazy
Copy link
Contributor

@mhegazy mhegazy commented May 2, 2016

Fixes #606

This supports completions in string literals in the following locations:

  1. argument to a call expression whose target parameter has a StringLiteralType

    declare function f(a: "A", b: number): void;
    declare function f(a: "B", b: number): void;
    declare function f(a: "C", b: number): void;
    
    f(" // A | B | C
  2. argument expression of an element access expression

    var o = {
    "#invlaid identifier name": 1
    };
    
    o["| // #invlaid identifier name
  3. a string literal contextually typed by a string literal type

    type Options = "Option 1" | "Option 2" | "Option 3";
    var x: Options = "| // Option 1 | Option 2 | Option 3

This PR does not cover:

  • module name completion
  • changing o. to o[""] if the completion entry is not a valid identifier name

}
}

function getStringLiteralCompletionEntriesFromCallExpression(argumentInfo: SignatureHelp.ArgumentListInfo) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can eventually generalize this logic to other types as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i suppose if we do pre-selecting of completion entries based on contextual type.

@DanielRosenwasser
Copy link
Member

Very cool! Looks like this doesn't include the quote character, right?

return undefined;
}

const argumentInfo = SignatureHelp.getContainingArgumentInfo(node, position, sourceFile);
Copy link
Member

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 getPossibleContextualTypes

Copy link
Contributor Author

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.

@mhegazy
Copy link
Contributor Author

mhegazy commented May 3, 2016

Very cool! Looks like this doesn't include the quote character, right?

yes. i am assuming here that automatic brace completion would get that done for you, or you have them written already.

we should add replaceText, and replaceRange on CompletionEntry, to allow that. there are some issues with Roslyn API currently that makes this hard, but i believe should be better in next version.

@mhegazy
Copy link
Contributor Author

mhegazy commented May 3, 2016

@yuit and @DanielRosenwasser any more comments?

if (argumentInfo) {
return getStringLiteralCompletionEntriesFromCallExpression(argumentInfo);
}
else if (isElementAccessExpression(node.parent) && node.parent.argumentExpression === node) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you have to check this "node.parent.argumentExpression === node"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"expression"["index"] want to make sure we are on "index"

@yuit
Copy link
Contributor

yuit commented May 3, 2016

others than the small comments, look good 🍰.

const entries: CompletionEntry[] = [];

if (isSourceFileJavaScript(sourceFile)) {
const uniqueNames = getCompletionEntriesFromSymbols(symbols, entries);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you start perform checking for characters?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure really. this is how it was before adding the argument. let me look more into it.

@mhegazy mhegazy merged commit 17b5415 into master Jun 8, 2016
@mhegazy mhegazy deleted the stringLiteralCompletions branch June 8, 2016 21:42
@Thaina
Copy link

Thaina commented Aug 3, 2016

Are there any jsdoc comment syntax I could made to use this feature in javascript with salsa?

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Aug 3, 2016

@Thaina check out #9902 and #9995.

@ghost ghost mentioned this pull request Jan 25, 2018
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants