Problem:
As it turns out, when you have 17 different ways to "exit", you need to
plug 17 different holes.
Leak still reported by ASAN CI, even after 1eae512285f238788601.
ERROR: LeakSanitizer: detected memory leaks
strbuf_init src/cjson/strbuf.c:62:22
json_create_config src/cjson/lua_cjson.c:635:5
lua_cjson_new src/cjson/lua_cjson.c:2060:5
nlua_state_add_stdlib src/nvim/lua/stdlib.c:840:3
nlua_state_init src/nvim/lua/executor.c:973:3
Analysis:
`os_breakcheck()` may process a `exit_event` placed by
`exit_on_closed_chan()` during shutdown. This would re-enter
`preserve_exit()`, which then skips everything because it sees
`really_exiting=true`.
Solution:
Set `exiting` in `preserve_exit()`, not only in `getout()`.
Problem:
SIGTERM received during `os_exit()` can cause it to "nest":
os_exit src/nvim/main.c:720
preserve_exit src/nvim/main.c:910
deadly_signal src/nvim/os/signal.c:205
on_signal src/nvim/os/signal.c:240
signal_event src/nvim/event/signal.c:45
multiqueue_process_events src/nvim/event/multiqueue.c:159
event_teardown src/nvim/main.c:178
os_exit src/nvim/main.c:720
Solution:
Call `signal_reject_deadly()` at the start of `os_exit()` like
`preserve_exit()` already does.
Problem:
TSan CI, always at exit:
WARNING: ThreadSanitizer: use of an invalid mutex (e.g. uninitialized or destroyed)
#1 uv_mutex_lock
#2 tui_flush src/nvim/tui/tui.c:1708
#3 ui_client_event_flush
#4 parse_msgpack src/nvim/msgpack_rpc/channel.c:259
...
#10 event_teardown src/nvim/main.c:187
#11 os_exit src/nvim/main.c:720
...
#19 tinput_done_event src/nvim/tui/input.c:184
Analysis (guess):
`rpc_close_event()` may run during `event_teardown()` and reattach to
a restarted server, then `ui_client_attached=true` gets set and redraws
resume in an already-stopped TUI.
Solution:
Check `!exiting` in `rpc_close_event`, like we already do in
`channel_proc_exit_cb()`.
Problem:
Unreliable test on slow CI (ASAN/TSAN):
FAILED .../tui_spec.lua @ 3054: TUI exits immediately when stdin is closed
retry() attempts: 1
Expected: vim.NIL
Actual: { name = "nvim", pid = 33201, ppid = -1 }
The test asserts "immediate" exit of the Nvim process, but this may be
subject to OS delays outside of our control.
Solution:
Make the "timed out waiting for DA1" log conditional on the actual
timeout, and assert the logs in the test.
Problem:
Leak reported by ASAN CI, always at Lua state init.
ERROR: LeakSanitizer: detected memory leaks
strbuf_init src/cjson/strbuf.c:62:22
json_create_config src/cjson/lua_cjson.c:635:5
lua_cjson_new src/cjson/lua_cjson.c:2060:5
nlua_state_add_stdlib src/nvim/lua/stdlib.c:840:3
nlua_state_init src/nvim/lua/executor.c:973:3
...
SUMMARY: AddressSanitizer: 1055 byte(s) leaked in 2 allocation(s).
Analysis:
`getout()` may run during `free_all_mem()` (that's why it checks
`!entered_free_all_mem`). If that happens, the second `os_exit()`
returns early from `free_all_mem()` then `exit()` is called and Lua
state is never closed.
Solution:
Always call `nlua_free_all_mem()` in the early-return case.
Problem:
- Dot-repeat of a Visual selection prepared by a `<Cmd>` mapping,
results in E1255 and leaves Visual mode active.
- Visual-mode capture is implemented as a second, parallel "capture
engine": it re-composes a CmdSpec from cmdarg_T per key and decides
replayability from its own table of "void" key classes.
Solution:
- Model nested `normal_execute()` as a `CmdFrame` stack,
instead of a single module-scoped `stage`.
- Capture `<Cmd>` ":norm …" commands as subatoms from its nested frames.
- Produce every command exactly once; atom_push_raw() routes the atom to
the Visual composite while a selection is open, like it already does
for mapping composites.
- `v/pat<CR>d` is now repeatable and cascades.
Problem:
Flaky test:
RUN T1158 nvim.zip reports an incorrect archive password: 11092.84 ms FAIL
The prompt is detected only if the pty output *ends* with "password: ",
but a read may return the prompt plus following bytes.
Solution:
- Match anywhere in the output since the last password was sent. The
buffer is cleared before each send, so won't match stale text.
- Assert on the reported message, so a failure shows what was reported.
Problem:
With the addition of the `:help al` text object, you can now easily
format the whole buffer with `gqal`. However, `vim.lsp.formatexpr` only
uses `textDocument/rangeFormatting` which some language servers (like
gopls) don't support.
Solution:
- Fall back to `textDocument/formatting` if the whole buffer is being formatted
and the server doesn't support `textDocument/rangeFormatting`.
- In theory, these two methods should return the same response if the whole
buffer is being formatted, but I preserved the existing behaviour of
prioritising `textDocument/rangeFormatting` in case that does not hold (i.e.
LS bug).
- Also: `vim.lsp.formatexpr` had no tests at all, so actually add tests for it.
Native Lua modules loaded with `require` or `package.loadlib` resolve Lua
C API symbols from the nvim executable itself. Those symbols must stay in
the binary even when nothing inside nvim references them.
`rdynamic` is enough on Linux. On macOS the linker dead-strips
unreferenced symbols before rdynamic exports them, so `_lua_tothread` is
missing from the executable and loading such a module fails with:
symbol not found in flat namespace '_lua_tothread'
Disable section garbage collection so all non-static symbols are kept.
vim-patch:8.2.0514: several global functions are used in only one file
vim-patch:8.2.1814: missing change to remove "static"
vim-patch:8.2.2860: adding a text property causes the whole window to be redawn
vim-patch:8.2.3276: Vim9: exists() can only be evaluated at runtime
vim-patch:8.2.3753: Vim9: function unreferenced while called is never deleted
vim-patch:8.2.4669: in compiled code len('string') is not inlined
vim-patch:9.0.1821: Vim9 constructors are always static
vim-patch:9.0.1953: Misplaced comment in errors.h
vim-patch:9.1.0349: Vim9: need static type for typealias
vim-patch:9.1.0584: Warning about redeclaring f_id() non-static
vim-patch:ae3a8664b runtime(doc): Add explanation for Vim's IME
vim-patch:9.1.2033: tests: Test_terminal_cwd flaky when using ConPTY
vim-patch:9.2.0026: The ss_pending_cmds variable is visible globally
vim-patch:9.2.0643: Missing Image ifdefs
vim-patch:381da9f85 CI: Bump github/codeql-action
vim-patch:9.2.0965: GTK4: blurry text rendering
vim-patch:9.2.0966: GTK4: window opens two lines too small
vim-patch:0b7700e1a runtime(doc): add PREVENT LOADING section for pi_getscript.txt
vim-patch:068657ffc runtime(vimlogo): remove coincident lines and reshade vimlogo.svg
vim-patch:8.2.0149: maintaining a Vim9 branch separately is more work
vim-patch:8.2.0173: build fails with old compiler
vim-patch:8.2.0191: cannot put a terminal in a popup window
vim-patch:8.2.0194: some commands can cause problems in terminal popup
vim-patch:8.2.0196: blocking commands for a finished job in a popup window
vim-patch:8.2.0202: when 'lazyredraw' is set the window title may not be updated
vim-patch:8.2.0204: crash when using winnr('j') in a popup window
vim-patch:8.2.0320: no Haiku support
vim-patch:8.2.0328: no redraw when leaving term-normal mode in popup terminal
vim-patch:8.2.0364: printf test failing on Haiku
vim-patch:8.2.0367: can use :pedit in a popup window
vim-patch:8.2.0399: various memory leaks
vim-patch:8.2.0516: client-server code is spread out
vim-patch:8.2.0557: no IPv6 support for channels
vim-patch:8.2.0574: ipv6 feature not shown in :version output
vim-patch:8.2.0588: Putty does not use "sgr" 'ttymouse' by default
vim-patch:8.2.0596: crash in test49
vim-patch:8.2.0611: Vim9: no check for space before #comment
vim-patch:8.2.0613: Vim9: no check for space before #comment
vim-patch:8.2.0624: Vim9: no check for space before #comment
vim-patch:8.2.0641: Vim9: not expanded in :hardcopy and syn-include
vim-patch:8.2.0650: Vim9: script function can be deleted
vim-patch:8.2.0653: using uninitialized pointer
vim-patch:8.2.0656: MS-Windows: redrawing right screen edge may not be needed
vim-patch:8.2.0694: Haiku: channel and terminal do not work
vim-patch:8.2.0718: gcc warning for returning pointer to local variable
vim-patch:8.2.0747: cannot forcefully close all popups
vim-patch:8.2.0748: cannot get a list of all popups
vim-patch:8.2.1601: Vim9: cannot use 'true" with garbagecollect()
vim-patch:8.2.1602: Vim9: cannot use 'true" with getbufinfo()
vim-patch:8.2.1603: Vim9: cannot use "true" with getchar()
vim-patch:8.2.1604: Vim9: cannot use "true" with getcompletion()
vim-patch:8.2.1606: Vim9: cannot use "true" with has()
vim-patch:8.2.1610: Vim9: cannot pass "true" to list2str() and str2list()
vim-patch:8.2.1611: Vim9: cannot pass "true" to nr2char()
vim-patch:8.2.1614: Vim9: cannot pass "true" to searchcount()
vim-patch:8.2.1615: Vim9: cannot pass "true" to searchdecl()
vim-patch:8.2.1616: Vim9: cannot pass "true" to synID()
vim-patch:8.2.1617: Vim9: cannot pass "true" to win_splitmove()
vim-patch:8.2.1619: Vim9: cannot pass "true" to spellsuggest()
vim-patch:8.2.4597: LuaV_debug() not covered by tests
vim-patch:8.2.4648: handling LSP messages is a bit slow
vim-patch:8.2.4650: "import autoload" only works with using 'runtimepath'
vim-patch:8.2.4653: "import autoload" does not check the file name
vim-patch:8.2.0528: Vim9: function arguments insufficiently tested
vim-patch:9.0.0375: the footer feature is unused
vim-patch:9.1.0202: leaking memory in add_user() on failure
Problem: The hit-enter prompt fires whenever a message scrolls the screen.
When this happens while a mapping is being processed, it consumes
the mapping's next key, causing unexpected behavior for users.
Solution: Similar to what 9.1.1969 did for stuffed characters, skip the
hit-enter prompt when there are still keys pending from a mapping
in the typeahead buffer.
related: neovim/neovim#38298
related: neovim/neovim#20635
related: neovim/neovim#30890
closes: vim/vim#20753
AI assisted.
6025ea9e02
Co-authored-by: XiaowenHu96 <me@xiaowenhu.com>
Problem: A SAL rule longer than MAXWLEN is silently truncated to an
empty lead. set_sal_first() then reorders the sl_sal entries
by their index byte and can move the terminating sentinel out
of the last slot, so spell_soundfold_wsal() reads past the end
of the array, e.g. when soundfold() or spellsuggest() is used
(Erick Alex).
Solution: Bound the sound-folding loops against sl_sal.ga_len.
closes: vim/vim#210766ac008db96
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problem: string_reduce() copies *rettv into argv[0] before calling
eval_expr_typval(). When the evaluator fails early, rettv is
never reset and still aliases argv[0] v_string.
clear_tv(&argv[0]) frees it, leaving rettv dangling and when
in vim9script get_func_tv() frees it again (Ave Dva).
Solution: Set rettv->v_type = VAR_UNKNOWN like what is done in
list_reduce() and tuple_reduce(), use tv_get_string_strict()
in f_reduce()
closes: vim/vim#21048
Supported by AI.
cd59994c45
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Informational message has an error message number.
Solution: Use a message without an error number. (closesvim/vim#11530)
b53a190e9f
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
`buffheader_T` is a linked list (Vim's favorite data structure) with
complex bookkeeping, optimized for ancient hardware:
1. Memory topology: On old platforms (Amiga 512KB without MMU, MS-DOS
64KB segments), large contiguous allocations were hazardous (no VM).
2. Never-move appends: `add_buff()` fills spare space or links a new
block.
3. OOM "recovery": a failed block allocation only loses one append.
To avoid OOM, it prefers to allocate small, linked chunks, instead of
resizing one continguous slice. Each stuff/drain cycle costs
a malloc+free.
Solution:
Replace Vim's favorite data structure with Nvim's favorite data structure.
Nvim doesn't have granular handling of OOM (`xmalloc`), and hardware has
changed: caches favor contiguous memory, allocators handle
fragmentation. And these buffers are ~kb scale, so OOM is irrelevant on
any system that can run Nvim.
- Use a flat `StringBuilder` + `read`/`insert` offsets.
- Keeps capacity (does not shrink) until `free_buff`.
- "Steady state" allocates nothing: 1 fewer malloc+free per dot-repeat.
Problem:
`RedoBuf` is mostly indirection. It has a mild benefit as an "ownership"
signal but it counteracts the general goal of unifying how "redo state"
is passed throughout the system, tends to sprout redundant interfaces,
and reduces clarity.
Solution:
Add `CmdSpec.body` to hold the "prefixless" key sequence.
Reuse `CmdSpec` to represent a "redo" buf.
Problem: Cannot show extra info for completion in a popup window.
Solution: Add the "popup" entry in 'completeopt'.
576a4a6ff1
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
Redo prep is scattered/duplicated.
- `do_pending_operator()` has 3 prep blocks whose conditions must be in
sync with `atom_capture_op()`.
- insert.c, spell_suggest() hand-roll `redo_new()` + `redo_append_xx()`
sequences.
- prep_redo() has 2 roles, decided by `keys != NULL`.
Solution:
- `atom_capture_op()` is the "operator" entry point: capture, then
prep.
- Extract `prep_redo_visual()`, `atom_capturable()`.
Problem:
When `z=` delegates to `vim.ui.select()`, the picker may change the
current window before returning. `spell_suggest()` then continues to the
cursor restoration branch with the new window and assigns `prev_cursor`,
which belongs to the original window. This can leave Normal mode with an
invalid cursor position and produce E315.
Solution:
Clean up the spell suggestion state and return immediately after handing
control to `vim.ui.select()`.
Follow-up refactor patches, mixed with unrelated patches in the middle,
is normal in vim-dev when the original patch is not fully tested
across all builds via CI or reviewed by others.
Unless core maintainers push "vim-patch:" directly to master/main branch
without running the full test-suite,
there is little reason to merge incomplete ports that will fail
on Nvim's CI or code review.
Relevant changes in patches like v8.2.0514 are either ported
or (will) become N/A.
Ignoring incompatible implementation,
TerminalOpen and TermOpen events are not 1-1.
"TerminalWinOpen" was accepted as N/A in
commit c7ee6af777 .
I planned to not do this to have more test cases
after manipulating the hunks header to filter out more hunks
but Justin is eager to just mark these N/A
to bump the Vim major.minor version.
Time to move on from v8.1.x.
Target v8.1.2195 .
Nvim did not port Vim's ":terminal" opts.
Incompatible implementations.
Ex-command was ported from C to Lua.
Vim needs them partly because of splitting the current window.
I keep forgetting `++close` option so I either run ":qall!"
or kill the parent process (ie. terminal emulator).
Unsatisfied users should create their Ex-command that runs jobstart().
Problem:
`<cmd>` mappings do not emit `CmdAtom.text`.
`<cmd>` and Lua-callback mappings that edit the buffer apply only at the
primary cursor, not cascaded (multicursor).
Solution:
Capture the `<cmd>` command in getcmdkeycmd().
Add kKeyOpaque ("no capturable keys"); narrow kKeySynthetic ("not
a keystroke") to K_EVENT/K_IGNORE, so an opaque mapping's edit still
sets `map_edit` and cascades via LHS-replay.
Problem:
`vim.fs.slug()` does not handle URIs like `term://foo//123:bash`,
so callers (e.g. terminal persistence) must strip the scheme before
calling `slug()`.
Solution:
Detect `scheme://` from the raw input before `normalize()` and
replace it with a `=uri-<scheme>-` prefix.
Problem:
`:rundo` on a corrupted undo file crashes or hangs, instead of failing
with E825. Patching one 4-byte field is enough:
ue_size = 0xFFFFFFFF " walks a NULL ue_array
ue_size = 0x7FFFFFF0 " 17 GB xmalloc + memset, then preserve_exit()
ue_top = 0xFFFFFFFB " negative lnum reaches ml_delete()
Analysis:
Every count in the file is read with `undo_read_4c()` and then checked,
differently at each site. None bounds the value by what the file can
hold, so a 2 GB count reaches `xmalloc()`.
Note:
- Vim doesn't have `bi_fsize` because it checks `U_ALLOC_LINE` result
everywhere (thus doesn't crash, but may thrash...); those checks were
dropped when Nvim moved to `xmalloc()`, and the `ue_size` loop counter
became unsigned.
- Vim *does* have the negative line numbers bug: `u_undoredo()` checks
`top > ml_line_count || top >= bot || bot > ml_line_count + 1`, which
rejects none of them.
Solution:
- Introduce `undo_read_len()` and use it to fail early instead of
continuing with nonsense.
- Validate `ue_top`/`ue_bot`/ `ue_lcount`.
- Use `xcalloc()`, so no site can proceed with a NULL array.
- Report a truncated "U" line, distinguish EOF from a 0xFFFFFFFF field,
and free the header on the extmark error path.
Problem:
Undo of a change spanning many paired marks is quadratic. A node's
"intersect" array holds every pair crossing that node, and both
intersect_node() and unintersect_node() walked it linearly. Undoing an
edit over 1M paired marks spends 68% of its time in unintersect_node()'s
scan alone.
Solution:
The array is sorted, so binary search it.
marks undo before after
200k 831ms 385ms
1M 14006ms 3820ms
Redo is unaffected: it is dominated by marktree_move() actually
repositioning the marks.
Problem:
A named mark updated after a change is moved back (treated as the
original mark) by undo:
:1mark d
:$
dw
:2mark d " 'd is on line 2
:undo " 'd is back on line 1
The undo header snapshots `b_namedm` when the change is recorded, and
`u_undoredo()` restores that snapshot indiscriminately.
Solution:
Update the pending header's snapshot when a mark is set explicitly.
Marks that the change itself moved go through mark_adjust(), not
setmark_pos(), so those are still reverted.
Similar to 2546741d1b (for extmarks): an explicit set inside an undo
block is confused with an edit-driven adjustment. But the extmarks case
is dealing with mid-edit moves, whereas named/regular marks only need
the stale snapshot dropped.
Problem:
Setting a :bcd buffer into another window, modifies the caller's CWD.
local b = vim.api.nvim_create_buf(true, true)
vim.api.nvim_buf_call(b, function() vim.cmd.bcd('..') end)
vim.cmd('vsplit')
vim.api.nvim_win_set_buf(vim.fn.win_getid(2), b)
:echo haslocaldir(0) haslocaldir(-1,0) haslocaldir(-1,-1,0)
0 0 0
:echo getcwd() ==# getcwd(-1,-1)
0
Analysis:
`ctx_dirs_save` only saves CWD if it predicts the switch can change it.
But win_set_buf() replaces the target window's buffer *after* the
switch, which cannot be "predicted" from `ctx_dirs_save`.
Solution:
Always snapshot whenever the switch enters another window.
Skipping `os_dirname` was a micro-optimization.
Problem:
nvim_win_set_buf() on a non-current win, while the current win has
a win-local dir, changes the global CWD:
:vsplit | lcd ..
:call nvim_win_set_buf(other_win, buf)
:wincmd l
:verbose pwd
[global] /parent " expected: the initial cwd
Analysis:
`globaldir` is where to return when no local dir applies; NULL means the
process CWD is already there. Switching to a window with no local dir
makes update_cwd() chdir back to `globaldir` and clear it. kCtxKeepCwd
restores the process CWD but not that bookkeeping, so the restored
window-local dir is mistaken for the global one.
Solution:
Save/restore `globaldir` with the CWD.
Problem:
A mark created by `nvim_buf_set_extmark()` while an undo block is open
never comes back on redo.
Analysis:
Undo deletes the text it covers and collapses the range; redo replays
the splices, which re-insert the text but cannot re-expand the mark.
`extmark_set()` records a position only for a mark it moves, not for one
it creates.
Solution:
Record the created position for redo; undo leaves the mark to the splice
replay, since it did not exist before the edit. Each side of a paired
mark gets its own entry. Redo also revives a mark that undo invalidated,
else its position returns but its highlight does not.
Vim's TerminalWinOpen seems to be required because of Vim
buffer-job-popupwin implementation.
Based on the patch, I'm puzzled why fzf needs this on Vim.
Nvim's TermOpen, TermEnter, and detection mechanisms to know
if buffer is on a (active,visible) window should suffice to not port it.
If there was a feature request or issue without a merged fix,
then I can't find it.
https://github.com/junegunn/fzf/pull/2000
