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 'data' property to completion entry for better coordination between completions and completion details #42890

Merged
merged 9 commits into from
Mar 1, 2021

Conversation

andrewbranch
Copy link
Member

@andrewbranch andrewbranch commented Feb 19, 2021

@typescript-bot
Copy link
Collaborator

Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @amcasey, @mjbvz, @minestarks for you. Feel free to loop in other consumers/maintainers if necessary

@andrewbranch andrewbranch changed the title Add 'data' property to completion entry for better cooperation between completions and completion details Add 'data' property to completion entry for better coordination between completions and completion details Feb 19, 2021
@uniqueiniquity
Copy link
Contributor

@andrewbranch As I work on the implementation for this, I'm hitting a couple issues:

  • when sending a completions-full request (Roslyn), I'm able to get the data object and send it back, but completionEntryDetails-full gives me the member import as a code action regardless of which data object I send back.
  • when sending a completionInfo request (LSP), I don't get the data object back in the completion item.

@andrewbranch
Copy link
Member Author

@uniqueiniquity the second of those problems should be fixed. The first I can’t reproduce with a server fourslash test, so we might have to debug together at some point.

@uniqueiniquity
Copy link
Contributor

As discussed offline, the first problem came from a TSServer plugin that patches getCompletionEntryDetails.
Every such plugin will need to be updated, or this functionality will no-op (i.e., two entries get added to the completion list that have the same behavior).

Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

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

I don't know enough to comment on the high-level concerns, but I looked over the code itself and only had one comment.

src/services/completions.ts Show resolved Hide resolved
src/services/services.ts Show resolved Hide resolved
});
}
}
}

function getAutoImportSymbolFromCompletionEntryData(data: CompletionEntryData): { symbol: Symbol, origin: SymbolOriginInfoExport } | undefined {
const containingProgram = data.isPackageJsonImport ? host.getPackageJsonAutoImportProvider!()! : program;
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 given that this is passed around we need to handle cases where data doesnt match what was passed around so instead of asserting we probably want to ensure that we handle if things are absent

Copy link
Member Author

@andrewbranch andrewbranch Feb 26, 2021

Choose a reason for hiding this comment

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

I don’t think that would make much difference—we already have an assertion later that getCompletionDetails can successfully find the completion by entryId. Even in master, if a bad client passed an incorrect name and source combination, we would trigger that assertion. We could easily return undefined here, but an assertion would be triggered a little bit later when we couldn’t find the module in question. I could replace some of this with a Debug.checkDefined but I think it’s generally better to fail fast if data violates the assumptions we hold.

@andrewbranch andrewbranch merged commit 993c503 into microsoft:master Mar 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Milestone Bug PRs that fix a bug with a specific milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Completion details can’t distinguish between a default export and a named export matching the filename
6 participants