[psteinroe]

Three ways a client request could break the server or the document state.

pgls.executeStatement without arguments panicked

The handler read params.arguments[0] and params.arguments[1] directly, so workspace/executeCommand with no arguments panicked in the handler. Malformed arguments came back as an internal error. Both are now InvalidParams errors with a message that says which argument is wrong.

Documents of other schemes shared the workspace document of a file

Session::file_path mapped every URI to its path, whatever the scheme, and the workspace keys documents by path. So:

• VS Code's git:/workspace/a.sql?{"ref":"HEAD"} (the left side of a diff) mapped to /workspace/a.sql. didOpen on it kept the existing document, and didClose removed the document of the real file. The next edit of the file failed with "not found", and its diagnostics were never published again.
• Every cell of a notebook (vscode-notebook-cell:/nb.ipynb#W0..., #W1...) mapped to the same path.
• untitled:Untitled-1 became the relative path Untitled-1, and ntitled-1 on Windows, where to_file_path strips the first character.

Only file: URIs map to file paths now. Other schemes are keyed by their whole URI, e.g. untitled:Untitled-1, which never equals a file's path and differs between notebook cells.

I gave them paths of their own rather than skipping them because untitled buffers and notebook cells are real editing surfaces, and people do write SQL in them. With their own key they keep diagnostics, completions and hover without touching any file's document. The trade-off is that path-based settings (files.include/ignore, the migrations directory) don't match them, which is right since they are not files. A git diff's old side is linted like any other buffer, which matches what VS Code does for other languages. The WASM worker's own documentSelector ({ language: 'sql' }) is unchanged.

Out-of-range positions failed the whole request

LineIndex::offset returned None for a line past the end, and a column past the end of a line ran into the next line or past the end of the text. Some clients send the line after the last one as the end of a range:

textDocument/inlayHint, range (0,0)-(2,0) on a two-line document without a final newline
-> Internal error: position Position { line: 2, character: 0 } is out of range

Positions from the client are now clamped (LineIndex::offset_clamped): a column past the end of its line means the end of the line, as the LSP specifies, and a line past the end means the end of the text. This applies to every handler that converts client positions (from_lsp::offset). The internal LineIndex::offset used for diffs stays exact. A huge UTF-16 column no longer overflows in wide_to_utf8_col. Inlay hints that can't be converted are left out with a warning instead of failing the response.

Tests

• execute_statement_without_arguments_is_invalid: no arguments, and arguments of the wrong type, both get InvalidParams.
• closing_a_document_of_another_scheme_keeps_the_file: open the file, open and close its git: version, edit the file. Diagnostics for the edit are published.
• test_inlay_hints_utf16_and_out_of_range: hints after an emoji land on the right UTF-16 columns, and a range that ends at the end of the line, past it, or on the line after the last one gets the same hints.
• Unit tests: document_path for file: (percent-decoding, drive colon), git:, notebook cells and untitled:, and clamping in UTF-16 including u32::MAX.

Not covered

fluent_uri (since #877) rejects URIs with unencoded spaces, so such a request fails to deserialize before it reaches the server. VS Code always encodes them, and fixing it would need a change in ls-types.