LSP completion echoes the unresolved identifier currently being typed as a Text item

[kuator]

🔎 Search Terms

completion echoes current identifier
completion suggests typed word itself
unresolved identifier completion
exact-match completion item
no-op completion item
completion item identical to current text
JavaScript IntelliSense current word
LSP completion Text item

🕗 Version & Regression Information

TypeScript version: 7.0.2
Server command: tsc --lsp --stdio

⏯ Playground Link

No response

💻 Code

somenonsenseicameupwithwhattheheck

🙁 Actual behavior

The completion response contains an item identical to the text currently being
typed:

{
  "label": "somenonsenseicameupwithwhattheheck",
  "kind": 1,
  "sortText": "18",
  "data": {
    "fileName": "/path/to/index.js",
    "name": "somenonsenseicameupwithwhattheheck",
    "position": 34
  }
}

Resolving the item with completionItem/resolve returns the same item without
documentation, detail, edits, a command, or any other side effect.

As a result, an LSP client can display a completion menu whose only candidate
is exactly the text already present. Accepting it does nothing.

This is the raw response from tsc; no editor-side word-completion provider is
involved.

🙂 Expected behavior

Consider omitting a completion item when all of the following are true:

• it is an unresolved Text item derived only from the identifier currently
  being completed;
• its label and insertion text are identical to the complete identifier;
• resolving it provides no documentation, detail, edits, command, or other
  effect.

Exact matches for real semantic symbols should remain. For example, the global
document completion is a Variable item and resolves to var document: Document with documentation, so it is useful even when its label exactly
matches the typed text.

If returning the unresolved Text item is intentional, could this behavior be
documented or made configurable?

Additional information about the issue

No response

[RyanCavanaugh]

This is intentional in positions that can introduce new identifiers. Some people have "complete on space" enabled, which would make it impossible to write code like

// Weird but syntactically legal:
doc => doc.toString();