Problem: Vim9: type can be assigned to list/dict
Solution: Prevent assigning a `type` to a `list` or `dict`
closes: #13683
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: not able to use imported interfaces and classes
Solution: Detect imported class/interfaces names correclty
fixes: #13661closes: #13685
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: instanceof() should use varargs as second arg
Solution: Modify `instanceof()` to use varargs instead of list
Modify `instanceof()` to use varargs instead of list
Valid `instanceof()` arguments are `type`s. A `type` is not a value;
it cannot be added to a list.
This change is non-compatible with the current usage of instanceof;
but instanceof is relatively new and it's a trivial change.
fixes: #13421closes: #13644
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in check_argument_type
Solution: Reset function type pointer when freeing the function type
list
function pointer fp->uf_func_type may point to the same memory, that was
allocated for fp->uf_type_list. However, when cleaning up a function
definition (e.g. because it was invalid), fp->uf_type_list will be
freed, but fp->uf_func_type may still point to the same (now) invalid
memory address.
So when freeing the fp->uf_type_list, check if fp->func_type points to
any of those types and if it does, reset the fp->uf_func_type pointer to
the t_func_any (default) type pointer
closes: #13652
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: incorrectly parses :def func definitions
Solution: check for more context when parsing function args
Signed-off-by: Christian Brabandt <cb@256bit.org>
Incorrectly parses def function definitions
Vim currently allows to define the following vim9 function:
def Func(f=
)
enddef
It currently thinks a Lambda is following the `=` but it doesn't check,
that there is actually an expression following. So when such a think is
encountered, remember that an expression should be following.
If no expression is coming in the next few lines, fail parsing the
function arguments, which will Vim no longer accept such a function.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: can use typealias in an assignment
Solution: Generate errors when class/typealias involved in the rhs of an
assignment
closes: #13637
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Generate errors when class/typealias involved in assignment.
Problem: Vim9: type not kept when assigning vars
Solution: When assigning a List or a Dict value to a variable of type
'any', keep the type
closes: #13639closes: #13646
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: The options[] array is not sorted alphabetically.
Solution: Sort it alphabetically. Add a test. Avoid unnecessary loop
iterations in findoption().
closes: #13648
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Using type unknown for List/Dict containers
Solution: Use 'any' instead
fixes: #13582closes: #13625
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: 'breakindent' is not drawn after diff filler lines.
Solution: Correct check for whether 'breakindent' should be drawn.
closes: #13624
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in exec_instructions()
Solution: get tv pointer again
[security]: use-after-free in exec_instructions()
exec_instructions may access freed memory, if the GA_GROWS_FAILS()
re-allocates memory. When this happens, the typval tv may still point to
now already freed memory. So let's get that pointer again and compare it
with tv. If those two pointers differ, tv is now invalid and we have to
refresh the tv pointer.
closes: #13621
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim does not detect pacman.log file
Solution: Detect pacmanlogs and add syntax highlighting
pacman.log is a filetype common to Arch Liux and related distributions.
Add some simple syntax highlighting for the pacmanlog filetype.
closes: #13618
Signed-off-by: Ronan Pigott <ronan@rjp.ie>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Type check tests fail without the channel feature
Solution: only run tests, when Vim was build with +channel
fixes: #13617closes: #13619
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: text-property without type errors when joining
Solution: count all text-properties, with or without type
before joining lines
Error when joining lines with text properties without a proper type
When joining lines, we need to consider all text properties that are
attached to a line, even when those text properties are invalid and do
not have a type attached to them.
However, since patch v9.0.0993
(commit: 89469d157a)
those text properties won't be counted when joining lines and therefore
this will cause the adjustment for text properties on joining to go
wrong (and may later cause SIGABRT with an invalid free pointer)
I am not sure, why the condition to not count text properties with a
valid type was added in patch v9.0.993, because no test fails if those
condition is removed. So let's just remove this condition and add a test
that verifies, that we are able to join lines, even when the text
properties attached to it do not have a valid type.
fixes: #13609closes: #13614
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Wrong scrolling in Insert mode with 'smoothscroll' at the
bottom of the window.
Solution: Don't use set_topline() when 'smoothscroll' is set.
fixes: #13612closes: #13613
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Text properties causes wrong line wrapping to be drawn.
Solution: Find the index of the last text property that inserts text.
closes: #13611
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: buffer-overflow in ex_substitute
Solution: clear memory after allocating
When allocating the new_start pointer in ex_substitute() the memory
pointer points to some garbage that the following for loop in
ex_cmds.c:4743 confuses and causes it to accessing the new_start pointer
beyond it's size, leading to a buffer-overlow.
So fix this by using alloc_clear() instead of alloc(), which will
clear the memory by NUL and therefore cause the loop to terminate
correctly.
Reported by @henices, thanks!
closes: #13596
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: stack-buffer-overflow in option callback functions
Solution: pass size of errbuf down the call stack, use snprintf()
instead of sprintf()
We pass the error buffer down to the option callback functions, but in
some parts of the code, we simply use sprintf(buf) to write into the error
buffer, which can overflow.
So let's pass down the length of the error buffer and use sprintf(buf, size)
instead.
Reported by @henices, thanks!
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: buffer-overflow in suggest_trie_walk
Solution: Check n before using it as index into byts array
Basically, n as an index into the byts array, can point to beyond the byts
array. So let's double check, that n is within the expected range after
incrementing it from sp->ts_curi and bail out if it would be invalid.
Reported by @henices, thanks!
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in win-enter
Solution: validate window pointer before calling win_enter()
win_goto() may stop visual mode, if it is active. However, this may in
turn trigger the ModeChanged autocommand, which could potentially free
the wp pointer which was valid before now became stale and points to now
freed memory.
So before calling win_enter(), let's verify one more time, that the
wp pointer still points to a valid window structure.
Reported by @henices, thanks!
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: html.angular ft is problematic
Solution: partly revert v9.0.2137
The html.angular filetype causes issues and does not trigger FileType
autocommands for the html or angular filetypes.
So let's roll back that particular change and detect this only as html
file
related: https://github.com/vim/vim/pull/13594#issuecomment-1834465890closes: #13604
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No test for mode() when executing Ex commands
Solution: Add some test cases and simplify several other test cases.
Also add a few more test cases for ModeChanged.
closes: #13588
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: ml_get error when scrolling after delete
Solution: mark topline to be validated in main_loop
if it is larger than current buffers line
count
reset_lnums() is called after e.g. TextChanged autocommands and it may
accidentally cause curwin->w_topline to become invalid, e.g. if the
autocommand has deleted some lines.
So verify that curwin->w_topline points to a valid line and if not, mark
the window to have w_topline recalculated in main_loop() in
update_topline() after reset_lnums() returns.
fixes: #13568fixes: #13578
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: not all nushell files detected
Solution: use *.nu to detect nushell files
closes: #13586
Signed-off-by: Daniel Buch Hansen <boogiewasthere@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in call_dfunc()
Solution: Refresh dfunc pointer
closes: #13571
This Commit fixes a SEGV caused by a use-after-free bug in call_dfunc().
When calling check_ufunc_arg_types() from the call_dfunc() it may cause
def functions to be re-compiled and if there are too many def functions,
the def_functions array will be re-allocated. Which means, that the
dfunc pointer in call_dfunc() now starts pointing to freed memory.
So we need to reset the dfunc pointer after calling
check_ufunc_arg_types().
Let's also add a test, to ensure we do not regress.
Signed-off-by: mityu <mityu.mail@gmail.com>
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add syntax and filetype plugins for SWIG (Simplified Wrapper Interface
Generator) description files.
The default syntax for .i files highlights comments in a reverse
color scheme which doesn't look well. This syntax builds
on vim's c++ syntax by adding highlighting for common swig
directives and user defined directives. For an alternative
syntax, see vimscript #1247 (which I found after writing this).
closes: #13562
Co-authored-by: Matěj Cepl <mcepl@cepl.eu>
Co-authored-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Unused assignments when checking the value of 'listchars'.
Solution: Loop only once when just checking the value. Add a test to
check that this change doesn't cause double-free.
closes: #13559
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: File info disappears immediately when 'cmdheight' has just
decreased due to switching tabpage and 'shortmess' doesn't
contain 'o' or 'O'.
Solution: Make sure msg_row isn't smaller than cmdline_row.
fixes: #13560closes: #13561
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Problem with initializing the length of range() lists
Solution: Set length explicitly when it shouldn't contain any items
range() may cause a wrong calculation of list length, which may later
then cause a segfault in list_find(). This is usually not a problem,
because range_list_materialize() calculates the length, when it
materializes the list.
In addition, in list_find() when the length of the range was wrongly
initialized, it may seem to be valid, so the check for list index
out-of-bounds will not be true, because it is called before the list is
actually materialized. And so we may eventually try to access a null
pointer, causing a segfault.
So this patch does 3 things:
- In f_range(), when we know that the list should be empty, explicitly
set the list->lv_len value to zero. This should happen, when
start is larger than end (in case the stride is positive) or
end is larger than start when the stride is negative.
This should fix the underlying issue properly. However,
- as a safety measure, let's check that the requested index is not
out of range one more time, after the list has been materialized
and return NULL in case it suddenly is.
- add a few more tests to verify the behaviour.
fixes: #13557closes: #13563
Co-authored-by: Tim Pope <tpope@github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: prevent overflow in indenting
Solution: use long long and remove cast to (int)
The shiftwidth option values are defined as being long. However, when
calculating the actual amount of indent, we cast down to (int), which
may cause the shiftwidth value to become negative and later it may even
cause Vim to try to allocate a huge amount of memory.
We already use long and long long variable types to calculate the indent
(and detect possible overflows), so the cast to (int) seems superfluous
and can be safely removed. So let's just remove the (int) cast and
calculate the indent using longs.
Additionally, the 'shiftwidth' option value is also used when determining
the actual 'cino' options. There it can again cause another overflow, so
make sure it is safe in parse_cino() as well.
fixes: #13554closes: #13555
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in ex_substitute
Solution: always allocate memory
closes: #13552
A recursive :substitute command could cause a heap-use-after free in Vim
(CVE-2023-48706).
The whole reproducible test is a bit tricky, I can only reproduce this
reliably when no previous substitution command has been used yet
(which is the reason, the test needs to run as first one in the
test_substitute.vim file) and as a combination of the `:~` command
together with a :s command that contains the special substitution atom `~\=`
which will make use of a sub-replace special atom and calls a vim script
function.
There was a comment in the existing :s code, that already makes the
`sub` variable allocate memory so that a recursive :s call won't be able
to cause any issues here, so this was known as a potential problem
already. But for the current test-case that one does not work, because
the substitution does not start with `\=` but with `~\=` (and since
there does not yet exist a previous substitution atom, Vim will simply
increment the `sub` pointer (which then was not allocated dynamically)
and later one happily use a sub-replace special expression (which could
then free the `sub` var).
The following commit fixes this, by making the sub var always using
allocated memory, which also means we need to free the pointer whenever
we leave the function. Since sub is now always an allocated variable,
we also do no longer need the sub_copy variable anymore, since this one
was used to indicated when sub pointed to allocated memory (and had
therefore to be freed on exit) and when not.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-c8qm-x72m-q53q
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No test for defining sign without attribute
Solution: Add test for defining sign without attributes
closes: #13544
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in shift_line
Solution: allow a max indent of INT_MAX
[security]: overflow in shift_line
When shifting lines in operator pending mode and using a very large
value, we may overflow the size of integer. Fix this by using a long
variable, testing if the result would be larger than INT_MAX and if so,
indent by INT_MAX value.
Special case: We cannot use long here, since on 32bit architectures (or
on Windows?), it typically cannot take larger values than a plain int,
so we have to use long long count, decide whether the resulting
multiplication of the shiftwidth value * amount is larger than INT_MAX
and if so, we will store INT_MAX as possible larges value in the long
long count variable.
Then we can safely cast it back to int when calling the functions to set
the indent (set_indent() or change_indent()). So this should be safe.
Add a test that when using a huge value in operator pending mode for
shifting, we will shift by INT_MAX
closes: #13535
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in get_number
Solution: Return 0 when the count gets too large
[security]: overflow in get_number
When using the z= command, we may overflow the count with values larger
than MAX_INT. So verify that we do not overflow and in case when an
overflow is detected, simply return 0
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in ex address parsing
Solution: Verify that lnum is positive, before substracting from
LONG_MAX
[security]: overflow in ex address parsing
When parsing relative ex addresses one may unintentionally cause an
overflow (because LONG_MAX - lnum will overflow for negative addresses).
So verify that lnum is actually positive before doing the overflow
check.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow in nv_z_get_count
Solution: break out, if count is too large
When getting the count for a normal z command, it may overflow for large
counts given. So verify, that we can safely store the result in a long.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large
If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.
Adds a test with INT_MAX as count and verify it correctly fails.
It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: FPE in adjust_plines_for_skipcol
Solution: don't divide by zero, return zero
Prevent a floating point exception when calculating w_skipcol (which can
happen with a small window when the number option is set and cpo+=n).
Add a test to verify
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it
If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.
Add a test to trigger ASAN in CI
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Skipcol is not reset when topline changed scrolling cursor to top
Solution: reset skipcol
closes: #13528closes: #13532
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: wast filetype should be replaced by wat filetype
Solution: start using the official wat filetype name
runtime: rename `wast` filetype to `wat` (Wasm text format)
The problem is the name of the current filetype wast. When the plugin
was initially created, the file extension for Wasm text format was not
fixed and .wast was more popular.
However, recently .wat became the official file extension for
WebAssembly text (WAT) format and .wast is now a file extension for the
unofficial WAST format, which is a superset of .wat for the convenience
to describe the Wasm specification conformance tests.
https://webassembly.js.org/docs/contrib-wat-vs-wast.html
However for now, let's keep using the `wat` filetype even for the .wast
extension, so that we at least do not lose the filetype settings and
syntax highlighting. This can be adjusted later, if it turns out to have
a separate need for.
closes: #13533
Signed-off-by: rhysd <lin90162@yahoo.co.jp>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: matchparen highlight not cleared in completion mode
Solution: Clear matchparen highlighting in completion mode
Remove hard-coded hack in insexpand.c to clear the :3match before
displaying the completion menu.
Add a test for matchparen highlighting. While at it, move all test tests
related to the matchparen plugin into a separate test file.
closes: #13493closes: #13524
Signed-off-by: Christian Brabandt <cb@256bit.org>
// related #12589
// that should be the last chat (I) with Bram, r.i.p
Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CI: test_termdebug may still fail
Solution: use term_wait() to make it more robust
closes: #13529
Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CI: test_termdebug fails
Solution: only test for a changed winlayout, if the window
width actually changed
Also, include an unrelated comment (which doesn't warrant its own patch
number)
Signed-off-by: Christian Brabandt <cb@256bit.org>
