Problem: the recursive parameter in the *_equal functions can be removed
Solution: Remove the recursive parameter in dict_equal(), list_equal()
object_equal and tv_equal(). Use a comparison of the static
var recursive_cnt == 0 to determine whether or not tv_equal()
has been called recursively (Yinzuo Jiang).
closes: #15070
Signed-off-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: eval.c is too long
Solution: Move garbage collection code to new gc.c file
(Yegappan Lakshmanan)
closes: #14824
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim is missing a foreach() func
Solution: Implement foreach({expr1}, {expr2}) function,
which applies {expr2} for each item in {expr1}
without changing it (Ernie Rael)
closes: #12166
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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: 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: Vim9: parsing commands with newlines wrong
Solution: Accept a '\n' for parsing lists and command arguments
closes: #13015closes: #13020
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Duplicate code to reverse a string
Solution: Move reverse_text() to strings.c and remove string_reverse().
closes: #12847
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: Fix regression in {func} argument of reduce()
Solution: pass function name as string again
Before patch 9.0.0548, passing a string as {func} argument of reduce()
is treated as a function name, but after patch 9.0.0548 it is treated as
an expression instead, which is useless as reduce() doesn't set any v:
variables. This PR restores the behavior of {func} before that patch.
Also correct an emsg() call, as e_string_list_or_blob_required doesn't
contain format specifiers.
closes: #12824
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: wrong error messages when passing wrong types to count()
Solution: fix it
This fixes two problems:
1. When passing wrong type to {ic} argument of count(), two error
messages are given, the second of which is misleading.
2. When passing wrong type to {comp} argument of count(), the error
message doesn't mention that {comp} may be a String.
closes: #12825
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: "clear" macros are not always used.
Solution: Use ALLOC_ONE, VIM_CLEAR, CLEAR_POINTER and CLEAR_FIELD in more
places. (Yegappan Lakshmanan, closes#12104)
Problem: Vim9: when copying a list it gets type list<any> even when the
original list did not have a type.
Solution: Only set the type when the original list has a type. (closes#9692)
Problem: Vim9: map() gives type error when type was not declared.
Solution: Only check the type when it was declared, like extend() does.
(closes#9635)
Problem: Vim9: type checking for list and dict lacks information about
declared type.
Solution: Add dv_decl_type and lv_decl_type. Refactor the type stack to
store two types in each entry.
Problem: Vim9: error when extending dict<any> with another type that it was
initialized with.
Solution: Also set the type for dict<any> if the initializer has a more
specific type. (closes#9461)
