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 completions from the 'this' type #21231

Merged
2 commits merged into from
Jan 17, 2018
Merged

Add completions from the 'this' type #21231

2 commits merged into from
Jan 17, 2018

Conversation

ghost
Copy link

@ghost ghost commented Jan 17, 2018

Fixes #21202

@ghost ghost requested a review from armanio123 January 17, 2018 17:27
return node && tryGetThisTypeAt(node);
},
isMemberSymbol: symbol =>
symbol.flags & SymbolFlags.ClassMember
Copy link
Author

Choose a reason for hiding this comment

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

Asked @sandersn and @weswigham and they didn't know why these are properties, but if I try to change undefined to a variable I can't build the compiler.

Copy link
Contributor

Choose a reason for hiding this comment

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

seems that this should be in utilities instead on the checker. nothing here is about the checker internal state, but rather how we mark symbols.

@ghost
Copy link
Author

ghost commented Jan 17, 2018

I think this one could use a second review. @sheetalkamat @weswigham @sandersn @rbuckton @mhegazy


function getInsertTextAndReplacementSpan(): { insertText?: string, replacementSpan?: TextSpan } {
if (kind === CompletionKind.Global) {
if (typeChecker.isMemberSymbol(symbol)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

seems kinda weird that we add the symbol, then later on ask the checker if they were the ones we added.. i wounder if we can do something different here..

Copy link
Contributor

Choose a reason for hiding this comment

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

alas.. i could not come up with a better idea here myself. ignore my previous rant.

Copy link
Author

@ghost ghost Jan 17, 2018

Choose a reason for hiding this comment

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

We could use SymbolOriginInfoMap with a union type { type: "this-type" } | { type: "export", ... }, would that be a good idea?

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah.. that is not bad..

isRecommended: trueOrUndefined(isRecommendedCompletionMatch(symbol, recommendedCompletion, typeChecker)),
...getInsertTextAndReplacementSpan(),
Copy link
Contributor

Choose a reason for hiding this comment

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

can we optimize this a bit instead of generating an extra object allocation on every entry.

let insertText: string | undefined;
let replacementSpan: TextSpan | undefined;
if (kind === CompletionKind.Global && origin && origin.type === "this-type") {
insertText = needsConvertPropertyAccess ? `this["${name}"]` : `this.${name}`;
Copy link
Member

Choose a reason for hiding this comment

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

do you not need replacement span eg. if refering to property x and you want to replace it with this.x ?

Copy link
Author

Choose a reason for hiding this comment

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

The default replacement span should already be the identifier itself. We only need to set replacementSpan if we are replacing something else, too, such as replacing .x with ["x"].

@ghost ghost merged commit 8ed885d into master Jan 17, 2018
@ghost ghost deleted the completionsThis branch January 17, 2018 20:05
@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018
This pull request was closed.
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.

3 participants