Problem:
This test would sometimes fail to match lines starting with `.` (indicating throttling) due to a race condition, likely because throttling completed before the test could properly assert.
Solution:
I 6x'd the amount of test data we were pushing into `nvim` in an attempt to trigger throttling consistently.
I don't _love_ this solution as it is still non-deterministic and might not hold up over time.
A good solution would be: create a deterministic way to pause neovim in a functional test, assert on the temporarily throttle state, then unpause neovim. However, it's likely this is not possible today and will take too much effort.
Before test time (30000 lines): ~0.40sec/run
After test time (150000 lines): ~1.7sec/run
This increases test runtime, but if it removes flakes I think it's worth it.
(cherry picked from commit cbedd537ac)
Problem: When an error line in a file passed to :cfile / :cgetfile is
longer than IOSIZE, qf_parse_file_pfx() copies the tail
into the fixed-size IObuff with STRMOVE(), overflowing the heap buffer.
The same code path can also loop indefinitely because
qf_parse_file_pfx() always returns QF_MULTISCAN when a
tail is present, and qf_init_ext() unconditionally goes
to "restofline" without bounding the tail length (Nabih).
Solution: Remove the STRMOVE() into IObuff. In the QF_MULTISCAN
branch, alias linebuf into the tail directly and update
linelen, requiring strict progress (new length less than
the previous length) before retrying; otherwise ignore
the line.
closes: vim/vim#20126
Supported by AI
77677c33de
Co-authored-by: Christian Brabandt <cb@256bit.org>
(cherry picked from commit 0e69a38026)
Problem:
`get_node_text()` returned inconsistent results between buffer and
string sources when a node's range ends at `end_col == 0` (i.e. the node
ends with a newline). The buffer path dropped the trailing newline; the
string path included it correctly.
Solution:
Append `'\n'` in `buf_range_get_text()` when `end_col == 0` and
`start_row ~= end_row`. The `start_row ~= end_row` guard excludes
zero-width nodes at column 0, which should return `""`.
Remove the workaround in the `#trim!` directive that manually
compensated for the missing newline.
Strip whitespace in `resolve_lang()` so injection language nodes ending
at `end_col == 0` (e.g. `">lua\n"`) still resolve correctly.
(cherry picked from commit 7ed5609439)
Problem: The with-external-deps workflow keeps failing because adding the neovim-ppa/stable times out.
Solution: Don't add the PPA; it doesn't seem to be necessary for installing current dependencies.
Problem: Optional CI reevaluates on unrelated label events and shares
one workflow-wide concurrency group. One optional label change can
cancel in-flight jobs for the other optional suite.
Solution: Only reevaluate each optional job when its own label changes,
and move concurrency to the job level. This keeps `s390x` and
`windows-asan` from restarting each other.
(cherry picked from commit 085bb518c8)
Problem:
LSP clients previously did not handle dynamic registration for off-spec methods
Solution:
Update the client logic to assume support for dynamic registration when
the method is unknown. Adjust the registration provider fallback and
enhance tests to verify correct behaviour for unknown methods and their
registration options. This improves compatibility with servers using
custom dynamic registrations.
AI-assisted: OpenCode
(cherry picked from commit 344d984ed2)
Problem:
The argument to `:help` is normalized to fit the general tag format.
I.e. i^U-default, iCTRL-U-default and i_CTRL_U-default should all point
to the i_CTRL_U-default tag. Our normalization adds an underscore around
the CTRL keycode, e.g. iCTRL-GCTRL-J becomes i_CTRL-G_CTRL-J. That's not
necessary if the following part starts with a dash, like the case of
iCTRL-U-default.
Solution:
Do not insert an underscore if the following character is a dash/minus
(-).
(cherry picked from commit 84ae70c172)
docs: update instructions for debugging LSP
Previously, it was suggested to set:
vim.lsp.log.set_format_func(vim.inspect)
This made sense before f72c13341a, when
`format_func` was called once per argument being logged, but since that
commit it's called with the log level followed by the other args, so the
suggested setting would call `vim.inspect(log_level, ....)` which would
just print the human readable name of the current log level and no other
details, for example with this set I saw in my logs:
"DEBUG""DEBUG""DEBUG""DEBUG"
Instead just rely on the default formatter, which will:
> ... log the level, date, source and line number of the
caller, followed by the arguments.
(cherry picked from commit 578727c25e)
fix(lsp): send didClose, didOpen when languageId changes
Problem:
If a buffer's filetype changes after the LSP client has already
attached (e.g. from json to jsonc via a modeline), but the client
supports both filetypes, it stays attached. It does not notify the
server of the new languageId, causing the server to incorrectly process
the file using the old languageId.
Solution:
Save the languageId used during textDocument/didOpen, and send
textDocument/didClose + textDocument/didOpen when buffer's languageId
changed.
Lsp spec:
0003fb53f1/_specifications/lsp/3.18/textDocument/didOpen.md (L5)
> If the language id of a document changes, the client
> needs to send a textDocument/didClose to the server followed by a
> textDocument/didOpen with the new language id if the server handles
> the new language id as well.
AI-assisted: Gemini 3.1 Pro
Co-authored-by: phanium <91544758+phanen@users.noreply.github.com>
Problem:
`v:starttime`, `:uptime` use a monotonic high-resolution timer. This
only works as long as the timer keeps running (if the computer is
suspended the timer is paused). This is somewhat unintuitive, and
doesn't match the behavior of the `uptime` shell command.
Solution:
Implement `os_realtime` to get the real time since the
epoch in nanoseconds.
Problem:
Error when querying document symbols using python-lsp-server:
lsp/util.lua:1955: attempt to concatenate field 'containerName' (a userdata value)
Solution:
Check for `vim.NIL`.
(cherry picked from commit 1799aaebda)
Calling `set print pretty on` in GDB will:
> Cause GDB to print structures in an indented format with one member
per line
However, `termdebug` just renders the newlines as raw `\n` characters.
This is a regression of[1]. Glancing through the history it looks to
have been caused by cd1b14f027 which
removed the output splitting when displaying the eval results, so this
changes adds that behaviour back.
As a quick reproduction/test, compile the following C program:
```c
struct Foo {
char *name;
};
int main(void) {
struct Foo f = {"hello"};
printf("%s\n", f.name);
return 0;
}
```
Then launch `nvim` and run:
:Termdebug main
:Gdb
(gdb) set print pretty on
(gdb) break main
(gdb) run
:Source
Place the cursor on the `f` variable and call `:Evaluate`. Before this change:
With this change:
Link: https://github.com/neovim/neovim/issues/10020 [1]
(cherry picked from commit c06e3d6f81)
Co-authored-by: Matthew Hughes <matthewhughes934@gmail.com>
Spell decorations from other lines aren't relevant to the current line.
Also, decor_redraw_col() can only go forward, while spell navigation
needs to go both forward and backward.
(cherry picked from commit 46c83ce321)
Problem:
Fields (key names) in classes, keysets, and quasi-keysets are ordered
randomly, which adds friction when reading docs.
Solution:
- Sort class fields and keysets when generating docs.
- Add a lint check for quasi-keysets (keysets defined as unstructured
markdown lists within a docstring).
Problem: The news workflow reruns on unrelated label events.
Solution: Only reevaluate the job when the changed label is
`ci:skip-news`.
(cherry picked from commit 1aeaa61bcf)
Problem: Plugins may want to have a way to show more details about items
when using `vim.ui.select`. This is a fairly common problem that
prompts plugin authors to implement dedicated sources/pickers for
fuzzy picker plugins that are popular at the moment.
Solution: Document a way for `vim.ui.select` to provide preview:
- `vim.ui.select` users can provide `opts.preview_item` function that
creates/uses a buffer and its contents at certain position to show
more details about an item.
- `vim.ui.select` implementations may use `opts.preview_item` in the
way they see fit (like show the buffer in a separate/same window
interactively/on-demand or do nothing) if they have a way to show
more information about an item.
(cherry picked from commit c44df255aa)
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem:
Since `foldclose` is async, it must wait for the request to return before actually executing, at which point the original window may no longer be valid.
Solution:
Check whether the window is valid before actually performing `foldclose`.
(cherry picked from commit 775c7d1b53)
Problem: When Nvim exits while connecting to a socket it leads to
stack-buffer-overflow.
Solution: Associate the handle with the Stream and use the Stream's
internal_close_cb to update the "closed" status.
(cherry picked from commit 4ed2e66d2e)
Problem:
The LSP client incorrectly checks for server capabilities when determining
support for self-mapped methods (e.g., 'shutdown'), which do not have
corresponding capabilities in the server's response. This leads to false
negatives when checking if such methods are supported.
This was handled correctly for dynamic registrations, but not for static.
Methods such as 'shutdown', do not have a related server capability and should
be assumed to be supported.
Solution:
Update the `supports_method` logic to always return true for self-mapped
methods.
(cherry picked from commit f83d0b9653)
Problem:
Invalid `nvim_create_user_command` calls can leak the
`preview` callback reference after Neovim has taken ownership of it.
1. build with {a,l}san
2. run:
```sh
<path/to/nvim> --headless -u NONE --clean +'lua
for i = 1, 100 do
pcall(vim.api.nvim_create_user_command,
"some very epic stuff" .. i,
{}, -- NOTE: this is INVALID (not a function or string)
{ preview = function() end })
end
vim.cmd("qa!")
' +qa
```
3. see:
```
100 lua references were leaked!
```
Solution:
Clear `preview_luaref` in `err:`.
(cherry picked from commit 393f687503)
Co-authored-by: Barrett Ruth <62671086+barrettruth@users.noreply.github.com>
Problem: `nvim_set_keymap` leaks the `callback` `LuaRef` when the
LHS is too long.
Solution: Make `set_maparg_lhs_rhs` transfer `rhs_lua` to
`MapArguments` up front so the caller always owns the ref.
(cherry picked from commit 58aad59e1c)
Co-authored-by: Barrett Ruth <62671086+barrettruth@users.noreply.github.com>
Problem:
`vim.secure.trust()` hashes an unchanged empty buffer as
a newline, so trusting an empty file by buffer never works.
Solution:
Hash unchanged empty-buffers `''` so buffer-based
trust matches the on-disk empty file.
(cherry picked from commit 0a8218a2b4)
Problem:
Use vim.lsp.util.apply_text_edits to re-apply the same textedit causes
an incorrect edit, because apply_text_edits silently modifies the
parameter.
Solution:
- Avoid changing `text_edit._index`.
- Document this fun feature.
Helped-by: Riley Bruins <ribru17@hotmail.com>
Helped-by: Yi Ming <ofseed@foxmail.com>
(cherry picked from commit 790a8be5f3)
Co-authored-by: geril07 <62308020+geril07@users.noreply.github.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
Cursor-position `vim.lsp.buf.code_action()` requests include all diagnostics on the current line, so unrelated same-line diagnostics affect the returned actions.
Solution:
Filter same-line diagnostics to the cursor position for cursor-position requests.
(cherry picked from commit ecb8402197)
Problem:
The fromRanges field of the result of callHierarchy/outgoingCalls is
documented as being relative to the caller. Using
vim.lsp.buf.outgoing_calls() opened the qflist with an entry with the
callee's filename, but the caller's line number.
Solution:
Open the qflist with the callers file (the bufnr from the request),
rather than the callees (the uri from the resulting CallHierarchyItem)
(cherry picked from commit 7e006b06c4)
Problem: Destroying a terminal with pending `TermRequest` events leaks
memory.
Solution: Make `emit_termrequest` the sole owner of its `pending_send`
allocation.
(cherry picked from commit 19ef632dec)
Problem:
LSP spec allows response message to have a null request-id.
This may happen when for example client sends unparseable request.
https://github.com/microsoft/language-server-protocol/issues/196
Solution:
Guard the server response branches against id=vim.NIL (json null),
and handle error responses with null id by logging a warning
and dispatching on error.
Problem:
CI (ubuntu asan, ubuntu tsan, windows) reports `uv_loop_close()
hang?` from the two new null-id response tests. The leaked
handle is the server-side accepted TCP socket created inside
`server:listen` callback. The tests closed only the listener
but not the accepted socket, so libuv could not finish shutting
down the loop and each test session took ~2s extra to exit.
Solution:
Hoist the accepted socket to the outer `exec_lua` scope and
close it at teardown before closing the listener. The close
runs synchronously inside `exec_lua`, so the loop has time to
dispose the handle before the session exits.
* test(lsp): close accepted socket on read-loop exit/error
Match the precedent in the handler test ("handler can return
false as response") and the shared `_create_tcp_server` helper
in `test/functional/plugin/lsp/testutil.lua`: close the
accepted socket from inside the `create_read_loop` exit/error
callbacks. The teardown close added in the previous commit
remains as belt-and-suspenders, so the socket is disposed
whether the server goes away first or the client does.
