Completion should filter non-type items when a type is expected

[auduchinok]

We should filter completion items in type annotations, interface ... with and inherit ... expressions.

[cartermp]

I'd be in favor of making a change right now, but I thing this is an excellent case where another provider (e.g., TypeDeclarationCompletionProvider) would make the most sense. This is the model Roslyn uses. I can kick off a spec for completion in the RFC repo and we can iterate on the types of providers which need to be added.

[auduchinok]

@cartermp I like the idea of having different providers. I'd be glad to have a separate provider for symbols in not-opened namespaces.
In this particular case we may add more cases to CompletionContext and look for it in either current APIs or in other added.

[vasily-kirichenko]

I'd be glad to have a separate provider for symbols in not-opened namespaces.

This is hard to do because you need to filter out symbols from opened namespaces, so you need the results from "normal" provider, which makes the whole separation idea meaningless.

[auduchinok]

@vasily-kirichenko When this completion is used in a project referencing ReSharper.SDK it sometimes takes much more time to get items from all namespaces in my case. However I couldn't reproduce it on any other projects.
The idea is not completely meaningless. In ReSharper a separate "long-working" provider may be implemented and its items will be added to the completion window when ready, opposite to items from "normal" providers where the completion window isn't shown until providers are ready.
We could filter items at early stages during completion calculation assuming we know all opened namespaces at location.

[cartermp]

@vasily-kirichenko

This is hard to do because you need to filter out symbols from opened namespaces

Sounds like this is the sort of thing worthy of a lengthy and detailed RFC process. Moving to a fully-fledged provider model would be great and give us the flexibility to fine-tune intellisense all-up, but the cost is a targeted redesign of this part of the language service.

[vasily-kirichenko]

@cartermp We discussed many details long time ago with no results, so I think any less fundamental but real progress is good.