Inconsistent filterText and textEdit are returned, violating the LSP spec

Completing the following line:

        java.util.concurrent.atomic.

In this case the server returns:

[Trace - 08:10:19 AM] Received response 'textDocument/completion - (166)' in 37ms.
Result: {
  "items": [
    {
      "data": {
        "uri": "file:///home/kyoncho/Sources/lsp/dap-mode/features/fixtures/test-project/src/main/java/temp/App.java",
        "rid": "20",
        "pid": "0",
        "decl_signature": "Ljava.util.concurrent.atomic.AtomicBoolean;"
      },
      "textEdit": {
        "newText": "java.util.concurrent.atomic.AtomicBoolean",
        "range": {
          "end": {
            "character": 36,
            "line": 9
          },
          "start": {
            "character": 8,
            "line": 9
          }
        }
      },
      "insertTextFormat": 2,
      "insertText": "AtomicBoolean",
      "filterText": "AtomicBoolean",
      "sortText": "999999180",
      "detail": "java.util.concurrent.atomic.AtomicBoolean",
      "kind": 7,
      "label": "AtomicBoolean - java.util.concurrent.atomic"
    },
....

As per spec the clients are supposed to use the textEdit range to find out where the completion has started and then filter it against filterText. In this case, the completion of prefix is calculated as java.util.concurrent.atomic. while the filter text is AtomicBoolean.

[yyoncho]

I guess it’s because in Case 2, instead of an empty string, vscode filtered the items using the full line java.util.concurrent.. I think @jrieken might know what’s happening behind. Is that a bug of vscode?

That is because JDT LS returns incorrect text range in Case 2 - the clients use Completion.textEdit.range to calculate what to filter against.

[jrieken]

the clients use Completion.textEdit.range to calculate what to filter against.

That’s correct - the range serves as the range that is replaced upon insertion and selects the prefix that’s used for filtering and sorting.