Why doesn't CompletionItem for std::thread include additionalTextEdits?

[jm-observer]

Hi, I'm developing a client that integrates with rust-analyzer, and I'm handling CompletionItem insertions.

When I complete something like thread, I get a CompletionItem that includes this field:

"data": {
  "imports": [{ "full_import_path": "std::thread" }]
}

However, the CompletionItem doesn't include any additionalTextEdits to insert use std::thread;.

My client does send completionItem.resolveSupport.properties = ["additionalTextEdits"], and I also call completionItem/resolve as needed.

Is this intentional behavior? Under what conditions does rust-analyzer decide to provide additionalTextEdits instead of data.imports? Should clients always handle data.imports themselves?

Thanks!

[flodiebold]

No, clients should never use anything in data, it's only for use by rust-analyzer for handling the resolve request. For an import completion there should always be additionalTextEdits (after resolve), as far as I can tell.

[Veykril]

Does the completion item change after the completionItem/resolve call?

[predragnikolic]

Someone reported the following issue for the LSP Sublime text client:

"Importing types via auto-complete sometimes doesn't import the type"
sublimelsp/LSP#2631

I initially thought that it was a client bug,
but I ended up finding that it is likely a bug in rust-analyzer.

sublimelsp/LSP#2633 (comment)

And here is why I think this is a server bug.

I have pushed 8b4a194 to make the bug more obvious.

The order of requests and notifications is the following:

1. send completion request
2. select item, (that will modify the document)
3. a didChange notification is send to the server
4. and to make the bug more obvious, I have put a set timeout of 1s to send the resolve completion > item, after the completion item has been selected and inserted.

To my discovery the rust-analyzer sever will successfully resolve completion items each time, > even after one second,
as long as the completion item doesn't contain the following text <...> in the label.

That said, if you have my branch checked out.
and select any completion item that is not in the red box,
when the resolve completion item request is send,
the server will successfully return additionalText edits
and auto imports will work always.

Else, if you select the completion items that have <...> in the label,
the resolve completion item request will never return additional text edits for them
and thus auto imports will not work.

[predragnikolic]

Rafal's comment is correct.

[rchl]

For Sublime Text the issue is on the editor side IMO as it doesn't wait for completion/resolveItem to finish before applying the completion and before next completion is triggered.

Maybe your client @jm-observer also makes a similar mistake? The completion should ideally be resolved before triggering a completion. Triggering another textDocument/completion request likely invalidates some data in rust-analyzer needed for resolving completion from the previous textDocument/completion request.

[jm-observer]

It took a bit too long, but after testing, there are no issues with my client either. Thank you all!