Skip to content

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.

7 participants