Suggestion for unnamed symbols completion: Offer completion for await

[MaStr11]

Brief description:

#47511 added support for completion of unnamed symbols. During the implementation it was suggested to add completion support for await and await someTask.ConfigureAwait(false).

This idea was postponed to not further complicate the PR:
#47511 (comment)

This feature would mimic dotnet/csharplang#4076 to some extent without actually implementing it as a language feature.

Languages applicable:

C#

Code example for the completion:

someTask.aw$$ // this triggers completion which contains "await" and "awaitf".
// committed suggestions ("await"):
await someTask$$
// or ("awaitf")
await someTask.ConfigureAwait(false)$$

Additional information:

The following characteristics would apply:

• Triggered after dot on the left side of the cursor (this includes null conditional member access)
• Expression on the left side of the dot must be task like
• Containing method must be marked with async
• Completion list contains await and awaitf
• Completion items are sorted alphabetical in between other members
• The completion item is an operator (operator glyph and filtered by the operator selection)
• The SymbolCompletionItem needs an underlying symbol. I think, Task.ContinueWith is a good choice, but causes some trouble with quick info (XMLDoc comment does not fit, overload count is just wrong and it will be difficult to prevent the completion list from merging the symbol with the real ContinueWith method symbols). It's propably better to synthesize a symbol, like it was done for the built-in conversions in Intellisense for cast, indexers and operators #47511.
• On completion, await is placed in front of the expression. The dot, that triggered completion and any partially written await is removed.
• On null conditional member access, the ? is left. This is in line with the behavior of conversion completion.
• On completion of awaitf, .ConfigureAwait(false) is additionally appended to the dot left of the cursor position
• Completion for null conditional member access and awaitf (someTask?.$$) completes to await someTask.ConfigureAwait(false)?$$
• Completion does not surround the resulting expression with parenthesis like so (await someTask)$$

[MaStr11]

/cc @CyrusNajmabadi AFAIK #47511 is internal testing. Should we wait until #47511 is settled before implementing this?

[CyrusNajmabadi]

This round just be a new completion provider. They're is already a pr it now to add async when typing await. After that goes in, we can consider this :-)

[CyrusNajmabadi]

We'd want #48352 to go in first. Here are a few more things i also noticed:

Containing method must be marked with async

I don't think this is necessary. If hte containing method is not marked with async, we should add it. I think this likely should be part of the new AwaitKeywordCOmpletionProvider that is being added.

The SymbolCompletionItem needs an underlying symbol

I don't think this is necessary. We jsut need a description saying something like "await the preceding expression", "await the preceding expression and add ConfigureAwait(false)" etc.

[MaStr11]

#48352 (blocking this issue) was merged two days ago, but the feature is not language agnostic:

Are you planning to add VB support in this PR?

I'll likely do that in a separate PR :(

https://github.com/dotnet/roslyn/pull/48352/files#r661758821

Looking at the code in #48352, there are several parts that should be reused here too:

• syntaxContext.IsAwaitKeywordContext Should await be suggested?
• shouldMakeContainerAsync Should the container be made async?
• IsComplexTextEdit handling in the AwaitCompletionProvider (adds async to the container).

@Youssef1313 are you going to implement VB support soon? @CyrusNajmabadi should we wait for VB support before implenting this issue?

[Youssef1313]

@MaStr11 Thanks for pinging. I'll look into supporting VB soon.

[MaStr11]

This round just be a new completion provider

@CyrusNajmabadi If I implement this as a new completion provider, I will have to call IRecommendationService.GetRecommendedSymbolsAtPosition to see if the expression type is task-like. Are there any performance concerns doing so? If so, we may need to integrate it into the UnnamedSymbolCompletionProvider.