summaryrefslogtreecommitdiffstatshomepage
path: root/test/unit/statusline_spec.lua
AgeCommit message (Collapse)AuthorFiles
2026-02-28vim-patch:9.2.0078: [security]: stack-buffer-overflow in build_stl_str_hl() ↵zeertzjq1
(#38102) Problem: A stack-buffer-overflow occurs when rendering a statusline with a multi-byte fill character on a very wide terminal. The size check in build_stl_str_hl() uses the cell width rather than the byte length, allowing the subsequent fill loop to write beyond the 4096-byte MAXPATHL buffer (ehdgks0627, un3xploitable). Solution: Update the size check to account for the byte length of the fill character (using MB_CHAR2LEN). Github Advisory: https://github.com/vim/vim/security/advisories/GHSA-gmqx-prf2-8mwf https://github.com/vim/vim/commit/4e5b9e31cb7484ad156fba995fdce3c9b075b5fd Co-authored-by: Christian Brabandt <cb@256bit.org>
2024-09-23refactor(api)!: rename Dictionary => DictJustin M. Keyes1
In the api_info() output: :new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val') ... {'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1} The `ArrayOf(Integer, 2)` return type didn't break clients when we added it, which is evidence that clients don't use the `return_type` field, thus renaming Dictionary => Dict in api_info() is not (in practice) a breaking change.
2024-04-10refactor(test): inject after_each differentlyLewis Russell1
2024-04-08test: improve test conventionsdundargoc1
Work on https://github.com/neovim/neovim/issues/27004.
2024-02-08refactor(api): refactor more api functions to use arena returnbfredl1
Currently having two separate memory strategies for API return values is a bit unnecessary, and mostly a consequence of converting the hot spot cases which needed it first. But there is really no downside to using arena everywhere (which implies also directly using strings which are allocated earlier or even statically, without copy). There only restriction is we need to know the size of arrays in advance, but this info can often be passed on from some earlier stage if it is missing. This collects some "small" cases. The more complex stuff will get a PR each.
2024-01-08refactor(options): use schar_T representation for fillchars and listcharsbfredl1
A bit big, but practically it was a lot simpler to change over all fillchars and all listchars at once, to not need to maintain two parallel implementations. This is mostly an internal refactor, but it also removes an arbitrary limitation: that 'fillchars' and 'listchars' values can only be single-codepoint characters. Now any character which fits into a single screen cell can be used.
2023-12-09refactor(options): reduce `findoption()` usageFamiu Haque1
Problem: Many places in the code use `findoption()` to access an option using its name, even if the option index is available. This is very slow because it requires looping through the options array over and over. Solution: Use option index instead of name wherever possible. Also introduce an `OptIndex` enum which contains the index for every option as enum constants, this eliminates the need to pass static option names as strings.
2023-12-04build: enable lintlua for test/unit/ dir #26396Justin M. Keyes1
Problem: Not all Lua code is checked by stylua. Automating code-style is an important mechanism for reducing time spent on accidental (non-essential) complexity. Solution: - Enable lintlua for `test/unit/` directory. - TODO: only `test/functional/` remains unchecked. previous: 45fe4d11add933df76a2ea4bf52ce8904f4a778b previous: 517f0cc634b985057da5b95cf4ad659ee456a77e
2023-09-30test(unit): move statusline tests to statusline_spec.lua (#25441)zeertzjq1