| Age | Commit message (Collapse) | Author | Files |
|---|
|
|
|
Problem:
The current LSP diagnostic implementation can't differ between a pull
diagnostic with no identifier and a set of diagnostics provided via push
diagnostics.
"Anonymous pull providers" are expected by the protocol https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticOptions
, depending on how the capability was registered:
- Dynamic registrations have an identifier.
- Static registrations will not.
Solution:
Restore the `is_pull` argument removed in
https://github.com/neovim/neovim/pull/37938, keeping the identifier of
pull diagnostic collections.
|
|
Introduce _provider_foreach to iterate over all matching provider
capabilities for a given LSP method, handling both static and dynamic
registrations. Update diagnostic logic and tests to use the new
iteration approach, simplifying capability access and improving
consistency across features.
|
|
Problem:
Regression from b99cdd0:
Pull diagnostics (from `textDocument/diagnostic`) and push diagnostics
(from `textDocument/publishDiagnostics`) use the same namespace, which
is a problem when using language servers that publish two different sets
of diagnostics on push vs pull, like rust-analyzer (see
https://github.com/rust-lang/rust-analyzer/issues/18709#issuecomment-2551394047).
Solution:
Rename `is_pull` to `pull_id` which accepts a pull namespace instead of
just a boolean.
|
|
- Refactor LSP client to use unified provider-based capability lookup for
diagnostics and other features.
- Introduce `_provider_value_get` to abstract capability retrieval,
supporting both static and dynamic registrations.
- Update diagnostic handling and protocol mappings to leverage
provider-centric logic.
|
|
Problem:
Diagnostic lifecycle invariants (clearing on empty publish and buffer
deletion) were previously implicit and not directly covered by functional
tests, allowing regressions to go unnoticed.
Solution:
Add functional regression tests asserting that diagnostics are cleared
when an LSP server publishes an empty diagnostic set and when the
associated buffer is deleted. Assertions are scoped to the client
diagnostic namespace and use public diagnostic APIs only.
|
|
Fix #36793
Also fix some `integer?` -> `integer` conversion warnings while at it.
|
|
#36754" (#36865)
This reverts commit 03d6cf7aae4a72c7221a4fb8ebb14a7c8603ba18.
See https://github.com/neovim/neovim/pull/36754#issuecomment-3626115697
The change was supposed to avoid showing stale diagnostics but had the
opposite effect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit makes it so that push diagnostics received for an outdated
document version are ignored.
|
|
* feat(lsp): deprecate `vim.lsp.stop_client`
* fix(tests): fix nil variable in diagnostic_spec.lua
|
|
|
|
|
|
|
|
**Problem:** For unchanged document diagnostic reports, the `resultId`
is ignored completely, even though it should still be saved for the
request (in fact, the spec marks it as mandatory for unchanged reports,
so it should be extra important).
**Solution:** Always store the `resultId`.
|
|
**Problem:** For multiline diagnostics, the end column was improperly
calculated by checking the byte index of the character position on the
*start* line.
**Solution:** Calculate the byte index for end_col using the *end* line.
|
|
Problem:
Users of the Roslyn (C#) LSP have encountered significant delays when
retrieving pull diagnostics in large documents while using Neovim. For
instance, diagnostics in a 2000-line .cs file can take over 20 seconds
to display after edits in Neovim, whereas in VS Code, diagnostics for
the same file are displayed almost instantly.
As [mparq noted](https://github.com/seblj/roslyn.nvim/issues/93#issuecomment-2508940330)
in https://github.com/seblj/roslyn.nvim/issues/93, VS Code leverages
additional parameters specified in the [LSP documentation for
textDocument/diagnostic](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#documentDiagnosticParams),
specifically:
- previousResultId
- identifier
Solution:
When requesting diagnostics, Neovim should include the
`previousResultId` and `identifier` parameters as part of the request.
These parameters enable the server to utilize caching and return
incremental results.
Support for maintaining state is already present in the
[textDocument/semanticTokens implementation](https://github.com/neovim/neovim/blob/8f84167c30692555d3332565605e8a625aebc43c/runtime/lua/vim/lsp/semantic_tokens.lua#L289).
A similar mechanism can be implemented in `textDocument/diagnostic` handler.
|
|
Problem:
LSP module has multiple "start" interfaces.
Solution:
- Enhance vim.lsp.start
- Deprecate vim.lsp.start_client
|
|
Co-authored-by: Jesse <github@jessebakker.com>
|
|
- Partition the handlers in vim.lsp.handlers as:
- client to server response handlers (RCS)
- server to client request handlers (RSC)
- server to client notification handlers (NSC)
Note use string indexes instead of protocol.methods for improved
typing in LuaLS (tip: use hover on RCS, RSC or NSC).
|
|
* deprecate old signatures
* move to new str_byteindex/str_utfindex signature
* use single-underscore name (double-underscore is reserved for Lua itself)
|
|
|
|
See https://github.com/microsoft/language-server-protocol/pull/1978
If the severity is not specified by the server, error should be used.
This was already the case because it matches the vim.diagnostic default.
This only adds a test case for it.
|
|
`buf.code_action` always included diagnostics on a given line from all
clients. Servers should only receive diagnostics they published, and in
the exact same format they sent it.
Should fix https://github.com/neovim/neovim/issues/29500
|
|
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
|
|
|
|
Work on https://github.com/neovim/neovim/issues/27004.
|
|
|
|
Problem:
`vim.lsp.diagnostic.on_diagnostic` accepts an undocumented severity_limit
option which is widely used.
Solution:
Deprecate it in favour of `{min = severity}` used in `vim.diagnostic`.
Since this is undocumented, the schedule for removal is accelerated to
0.11.
|
|
|
|
connected (#24535)
This fixes the issue where the LspNotify handlers for inlay_hint /
diagnostics would end up refreshing all attached clients.
The handler would call util._refresh, which called
vim.lsp.buf_request, which calls the method on all attached clients.
Now util._refresh takes an optional client_id parameter, which is used
to specify a specific client to update.
This commit also fixes util._refresh's handling of the `only_visible`
flag. Previously if `only_visible` was false, two requests would be made
to the server: one for the visible region, and one for the entire file.
Co-authored-by: Stanislav Asunkin <1353637+stasjok@users.noreply.github.com>
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
|
|
|
|
The LSP spec supports two tags that can be added to diagnostics:
unnecessary and deprecated. Extend vim.diagnostic to be able to handle
these.
|
|
* refactor(lsp): use autocmd api
* refactor(lsp): inline BufWritePost and VimLeavePre callbacks
|
|
Some language servers send empty `textDocument/publishDiagnostics`
messages after indexing the project with URIs corresponding to unopened buffers.
This commit guards against opening buffers corresponding to empty diagnostics.
|
|
|
|
Rather than treating virtual_text, signs, and underline specially,
introduce the concept of generic "handlers", of which those three are
simply the defaults bundled with Nvim. Handlers are called in
`vim.diagnostic.show()` and `vim.diagnostic.hide()` and are used to
handle how diagnostics are displayed.
|
|
* preserve fields from LSP diagnostics via adding a user_data table to the diagnostic, which can hold arbitrary data in addition to the lsp diagnostic information.
|
|
These links were actually defined backwards: the highlight groups
actually being used for display are the new "Diagnostic*" groups, so
linking the old "LspDiagnostics*" groups to these does absolutely
nothing, since there is nothing actually being highlighted with the
LspDiagnostics* groups.
These links were made in an attempt to preserve backward compatibility
with existing colorschemes. We could reverse the links to maintain this
preservation, but then that disallows us from actually defining default
values for the new highlight groups.
Instead, just remove the links and be done with the old LspDiagnostics*
highlight groups.
This is not technically a breaking change: the breaking change already
happened in #15585, but this PR just makes that explicit.
|
|
|
|
This generalizes diagnostic handling outside of just the scope of LSP.
LSP clients are now a specific case of a diagnostic producer, but the
diagnostic subsystem is decoupled from the LSP subsystem (or will be,
eventually).
More discussion at [1].
[1]: https://github.com/neovim/neovim/pull/15585
|
|
Previously, the handler signature was:
function(err, method, params, client_id, bufnr, config)
In order to better support external plugins that wish to extend the
protocol, there is other information which would be advantageous to
forward to the client, such as the original params of the request that
generated the callback.
In order to do this, we would need to break symmetry of the handlers, to
add an additional "params" as the 7th argument.
Instead, this PR changes the signature of the handlers to:
function(err, result, ctx, config)
where ctx (the context) includes params, client_id, and bufnr. This also leaves
flexibility for future use-cases.
BREAKING_CHANGE: changes the signature of the built-in client handlers, requiring
updating handler calls
|
|
Add two new methods to allow diagnostics to be disabled (and re-enabled)
in the current buffer. When diagnostics are disabled they are simply not
displayed to the user, but they are still sent by the server and
processed by the client.
Disabling diagnostics can be helpful in a number of scenarios. For
example, if one is working on a buffer with an overwhelming amount of
diagnostic warnings it can be helpful to simply disable diagnostics
without disabling the LSP client entirely. This also allows users more
flexibility on when and how they may want diagnostic information to be
displayed. For example, some users may not want to display diagnostic
information until after the buffer is first written.
|
