LSP 3.16: Consider implementing completionItem/resolve

[kjeremy]

If the client supports it we should implementing completionItem/resolve

[SomeoneToIgnore]

If the client supports it

What is a good way to understand this?
I've checked ClientCapabilities but did not find anything solid.

I see this when RA starts and gets info from VSCode:

resolve_support: Some(
    CompletionItemCapabilityResolveSupport {
        properties: [
            "documentation",
            "detail",
            "additionalTextEdits",
        ],
    },
),

in the completion capabilities, in Rust code this is

pub struct CompletionItemCapabilityResolveSupport {
    /// The properties that a client can resolve lazily.
    pub properties: Vec<String>,
}

Is it all right to check this vec for additionalTextEdits presence when I want to be sure that I can propose auto imports?

[kjeremy]

You will need to check if this exists: https://github.com/gluon-lang/lsp-types/blob/master/src/completion.rs#L109 and see what the properties are that it supports.

The vscode client is filled out like so: https://github.com/microsoft/vscode-languageserver-node/blob/fde994bb4e29518a1988d0070e3f160146135021/client/src/common/client.ts#L1514

[kjeremy]

Is it all right to check this vec for additionalTextEdits presence when I want to be sure that I can propose auto imports?

Yes. I would hang something off of our config infra that says what we can resolve lazily and check that when computing the completion. Then that could be deferred. We may need to make it generic for all completions (I haven't looked at our completion infrastructure in a while).

[kjeremy]

Oh... we also need to advertise server-side support by filling in CompletionOptions::resolve_provider so that the client knows it's supported.

[SomeoneToIgnore]

Yep, the server side is covered, but the client side is a bit obscure tbh.

Thank you for the advices.

[kjeremy]

It is awkward. You have to read https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#textDocument_completion a bunch.

From my understanding it works like this (assuming that the server advertises resolve) on LSP < 3.16:

1. The client makes a completion request
2. The server sends back a completion item.
3. The user selects the item in the list and if the completion item does not have details or documentation filled in it sends a resolve request with that completion item otherwise it uses that item.
4. The server responds with the completion item with either details/documentation filled in.

On LSP 3.16+ step 3 is different IF the client fills in resolveSupport. In that case other items besides just details and documentation can be resolved lazily (additionalTextEdits being the big one). Note that details and documentation are specified in that list to be backwards compatible with 3.15.

[kjeremy]

Thanks for doing this! I don't think we need to support documentation or detail to close this issue since they're cheap to compute. We can gradually move other completion items over to resolve as the need arises.

[SomeoneToIgnore]

I was just about to write a set of instructions on what to do next here, thanks for saving my time.

[kjeremy]

@SomeoneToIgnore feel free to open a new issue about enhancing this exciting and thrilling feature! If you have thoughts on improvements or specific instructions we probably shouldn't lose them.