Force public APIs to return complete results #68804
Conversation
External consumers of CompletionService (for unit testing CompletionProvider implementations) don't have access to the waiter APIs necessary to use non-blocking completion in testing scenarios. These APIs are updated to adhere to their behavior prior to dotnet#64352 introducing non-deterministic results.
dotnet-issue-labeler
bot
added
Area-IDE
untriaged
|
Just to verify though. Existing callers in Vs/vscode will still benefit here and can then the paths that may produce incomplete results faster, right? |
|
@CyrusNajmabadi Existing behavior for VS scenario does not change. Whether VS Code uses the old path or the new path is unclear, but in either case it would be acceptable. |
| // https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1620947 | ||
| if (options.ForceExpandedCompletionIndexCreation) |
There was a problem hiding this comment.
The fix looks good to me. But I'd suggest to change the name of this option to be more general to reflect this change.
There was a problem hiding this comment.
➡️ I left the option name the same, but updated the comment
Our LSP handler uses the internal API, so it's not affected by this (i.e. not waiting for provider from reference to be loaded before returning) |
ghost
added this to the 
External consumers of CompletionService (for unit testing CompletionProvider implementations) don't have access to the waiter APIs necessary to use non-blocking completion in testing scenarios. These APIs are updated to adhere to their behavior prior to #64352 introducing non-deterministic results.