Problem: Vim9: Can set environment variables in restricted mode
Solution: Disallow settings variables in exec_instructions() when in
restricted mode (pyllyukko)
related: #13394
closes: #19705
Signed-off-by: pyllyukko <pyllyukko@maimed.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: concatenation can be improved
Solution: Cache string segments lengths in exe_concat() and avoid
strlen() calls (John Marriott).
closes: #19647
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Not always using GA_CONCAT_LITERAL with string literals.
(after: v9.2.0031)
Solution: Use the GA_CONCAT_LITERAL, instead of ga_concat_len.
(John Marriott)
closes: #19468
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: more truthiness issues
(kennypete)
Solution: Class, enum and typealias cannot be used with the falsy
operator (Yegappan Lakshmanan)
related: #19213
fixes: #19173
closes: #19216
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: type issue when appending item to a list
(Peter Kenny)
Solution: When adding a new item at the end of a list in vim9script, use
the proper item type (Yegappan Lakshmanan)
fixes: #19045closes: #19076
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Can't unpack tuple from imported function
(Mao-Yining)
Solution: Support multi-variable assignment from a tuple returned by an
imported function (Yegappan Lakshmanan)
fixes: #19080closes: #19083
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: inefficient use of ga_concat()
Solution: Use ga_concat_len() when length is known.
(John Marriott)
closes: #19027
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: class and object member names are stored as char_u *
pointer requiring repeated strlen() calls and making it harder
to use length-aware string operations consistently.
Solution: Store ocm_name as a string_T instead of char_u *
(John Marriott).
In addition in vim9class.c:
1: change some calls from ga_concat() to ga_concat_len() where the
length is known.
2: in ex_class() remove unneeded variable name.
3. in intf_method_present() remove unneeded variable cl_name.
4: in update_member_method_lookup_table() move some assignments from
inner loops into outer loops.
5: in member_lookup() remove unneeded else.
6: in is_duplicate_variable() and is_duplicate_enum() rearrange the
string comparisons to first check the lengths match.
closes: #18973
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: class_name definition can be improved
Solution: Use string_T to store class_name, avoid using STRLEN() calls,
simplify code, remove unused definition of struct
oc_newmember_S (John Marriott)
Use struct string_T to store the field class_name in struct class_T,
which means we can just use the .length field in struct string_T
instead of measuring it.
In addition:
1. In eval.c use string_T to store class_name and s in function
class_tv2string().
2. In vim9type.c change some calls from ga_concat() to ga_concat_len()
where the length is known.
3. In vim9class.c remove unused struct definition oc_newmember_S.
Change some calls from ga_concat() to ga_concat_len() where the
length is known.
4. In scriptfile.c use string_T to store type_name, class_name and
es_name in function estack_sfile().
5. In function estack_sfile() simplify construction of the grow array ga
and change some calls from ga_concat() to ga_concat_len() when the
length is known.
closes: #18925
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Setting a byte in a blob, accepts values outside 0-255
Solution: When setting a byte in a blob, check for valid values
(Yegappan Lakshmanan)
closes: #18870
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Crash when using a lambda funcref with :defer
Solution: De-reference the partial correctly after invoking the deferred
functions (Yegappan Lakshmanan).
closes: #18640
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Generating prototype files does not work on all platforms
Solution: Rework prototypes generation using python instead of cproto,
enable it in CI to test it for each PR (Hirohito Higashi).
closes: #18045
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: possible variable type change when using closure in a
for loop (Maxim Kim)
Solution: Use unwind_locals(..., TRUE) (Yegappan Lakshmanan)
fixes: #17844closes: #17951
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: no generic support yet
Solution: Add support for generic functions, funcrefs and object/class
methods (Yegappan Lakshmanan).
closes: #17313
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim script is missing the tuple data type
Solution: Add support for the tuple data type
(Yegappan Lakshmanan)
closes: #16776
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: wrong context being used when evaluating class member
(lifepillar, Ernie Rael)
Solution: Use the correct script context when evaluating a class member
init expression(Yegappan Lakshmanan)
fixes: #14011fixes: #14402closes: #15112closes: #16660
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: Not able to use an autoloaded class from another
autoloaded script (Elliot)
Solution: make it work (Yegappan Lakshmanan)
fixes: #15031closes: #16652
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: import with extends may crash, v9.1.1087 wasn't the
correct way to fix it)
Solution: When using an import class, Check for a valid class member
variable at compile time (Yegappan Lakshmanan)
related: #16601closes: #16603
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: import with extends may crash
Solution: check otv for being NULL before trying to access it
(Hirohito Higashi)
closes: #16601
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: leaking finished exception
(after v9.1.0984)
Solution: use finish_exception to clean up caught exceptions
(Yee Cheng Chin)
In Vimscript, v:exception/throwpoint/stacktrace are supposed to reflect
the currently caught exception, and be popped after the exception is
finished (via endtry, finally, or a thrown exception inside catch).
Vim9script does not handle this properly, and leaks them instead. This
is clearly visible when launching GVim with menu enabled. A caught
exception inside the s:BMShow() in menu.vim would show up when querying
`v:stacktrace` even though the exception was already caught and handled.
To fix this, just use the same functionality as Vimscript by calling
`finish_exception` to properly restore the states. Note that this
assumes `current_exception` is always the same as `caught_stack` which
believe should be the case.
Added tests for this. Also fix up test_stacktrace to properly test the
stack restore behavior where we have nested exceptions in catch blocks
and to also test the vim9script functionality properly.
- Also, remove its dependency on explicitly checking a line number in
runtest.vim which is a very fragile way to write tests as any minor
change in runtest.vim (shared among all tests) would require changing
test_stacktrace.vim. We don't actually need such granularity in the
test.
closes: #16413
Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: double-free after v9.1.0988
(h-east)
Solution: clear typval pointer, before setting the type
(Yegappan Lakshmanan)
Otherwise the contents are still referring to some other value.
fixes: #16386closes: #16388
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: no error when using uninitialized var in new()
(lifepillar, Aliaksei Budavei)
Solution: Give an error if an uninitialized object variable is referenced
in new() (Yegappan Lakshmanan)
fixes: #14411fixes: #16344closes: #16374
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: VMS: build errors on VMS architecture
Solution: define cellsize struct, use C89 to initialize lval_root_S
struct (Zoltan Arpadffy)
* define struct cellsize for VMS
* ensures the code adheres to the C89 standard
closes: #16328
Signed-off-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: missing type checking for any type assignment
(Ernie Rael)
Solution: when assigning to a list item, if the type of the LHS item is
any, then use the list item type (Yegappan Lakshmanan)
fixes: #15208closes: #16274
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: no runtime check for object member access of any var
(after: 9.1.0850)
Solution: Add runtime type compatibility check for object member
accessed using a any variable (Yegappan Lakshmanan).
closes: #16037
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: cannot access nested object inside objects
(lifepillar, 91khr, mawkish)
Solution: Add support for accessing an object member using a "any"
variable type (Yegappan Lakshmanan)
fixes: #11822fixes: #12024fixes: #12196fixes: #12198closes: #16029
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: too recursive func calls when calling super-class method
with non-overriden super-call methods. (Aliaksei Budavei)
Solution: use interface method, when super is to be used (Ernie Rael)
When compiling "super.Func()" force class context to class that defines
function that is doing "super.Func()".
ISN_METHODCALL arg "cmf_is_super" for specific ufunc.
fixes: #15448fixes: #15463 (2) super.method may not execute in context of defining
class
closes: #15477
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: problem when importing autoloaded scripts
Solution: In `:def` handle storing to vim9 autoload export
(Ernie Rael)
Problem occurs when `import autoload ./.../autoload/...`. The autoload
in the specified path causes the use of an autoload_prefix which combines
with the `import autoload` to create trouble.
In `generate_store_var()` `case dest_script` use ISN_STOREEXPORT,
when needed, instead of ISN_STORES. When executing ISN_STOREEXPORT,
check for autoload_prefix.
fixes: #14606closes: #14615
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: String interpolation fails for List type
Solution: use implicit string(list) for string interpolation and :put =
(Yegappan Lakshmanan)
related: #14529closes: #14556
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: String interpolation fails for Dict type
Solution: Support Dict data type properly, also support :put =Dict
(without having to convert it to string() first)
(Yegappan Lakshmanan)
fixes: #14529closes: #14541
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The following is a collection of some small fixes:
- Problem: Vim9: funcref pointer pt leaks, when function is not found
Solution: Free funcref pointer in case of error (fixes: #14254)
- Problem: memory leak of crypt state pointer allocation fails
Solution: free crypt state pointer properly (fixes: #14253)
- Problem: Vim9: Leaking memory when compiling dict fails
Solution: Free the memory in case of error (fixes: #14252)
- Problem: Coverity complains about derefencing obj_members pointer
(after v9.1.0261)
Solution: Verify that obj_members ptr is non-null before accessing it
References: https://scan5.scan.coverity.com/#/project-view/41242/10101?selectedIssue=1596133closes: #14412
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: no support for const/final class/objects vars
Solution: Support final and const object and class variables
closes: #13655
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: can use type a func arg/return value
Solution: Check if using type as function argument or return value
closes: #13675
Signed-off-by: Ernie Rael <errael@raelity.com>
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: [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: [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>
Problem: several problems with type aliases
Solution: Check for more error conditions, add tests,
fix issues
Check for more error conditions and add additional tests
fixes #13434
fixes #13437
fixes #13438closes#13441
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: No support for type aliases
Solution: Implement :type command
A type definition is giving a name to a type specification. This also known
type alias.
:type ListOfStrings = list<string>
The type alias can be used wherever a built-in type can be used. The type
alias name must start with an upper case character.
closes: #13407
Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: crash with deferred function call and exception
Solution: Save and restore exception state
Crash when a deferred function is called after an exception and another
exception is thrown
closes: #13376closes: #13377
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
pyllyukko
John Marriott
Huihui Huang
Yegappan Lakshmanan
Hirohito Higashi
64-bitman
Christian Brabandt
Yee Cheng Chin
Zoltan Arpadffy
Ernie Rael
mityu