summaryrefslogtreecommitdiffstats
path: root/src/evalvars.c
AgeCommit message (Collapse)Author
2024-03-28patch 9.1.0219: Vim9: No enum supportv9.1.0219Yegappan Lakshmanan
Problem: No enum support Solution: Implement enums for Vim9 script (Yegappan Lakshmanan) closes: #14224 Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-03-09patch 9.1.0160: Vim9: Add support for using a class type of itself in an ↵v9.1.0160Yegappan Lakshmanan
object method Problem: Add support for using a class type of itself in an object method (thinca) Solution: Vim9: Add support for using a class type of itself in an object method (Yegappan Lakshmanan) fixes: #12369 closes: #14165 Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-02-12patch 9.1.0102: settabvar() may change the last accessed tabpagev9.1.0102zeertzjq
Problem: settabvar() may change the last accessed tabpage. Solution: Save and restore lastused_tabpage. (zeertzjq) closes: #14017 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-02-06patch 9.1.0080: unexpected error for modifying final list using +=v9.1.0080Yegappan Lakshmanan
Problem: unexpected error for modifying final list using += operator (Ernie Rael) Solution: Allow List value modification of a final variable using += operator (Yegappan Lakshmanan) fixes: #13745 fixes: #13959 closes: #13962 Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-16patch 9.1.0034: Window scrolls unexpectedly when 'scrollbind' is setv9.1.0034Christian Brabandt
Problem: Window may unexpectedly scroll when 'scrollbind' is set and setting a buffer-local option using setbufvar() (Boris Staletic) Solution: Save and restore the windows topline before opening the popup window. fixes: #13863 closes: #13869 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-04patch 9.1.0006: is*() and to*() function may be unsafev9.1.0006Keith Thompson
Problem: is*() and to*() function may be unsafe Solution: Add SAFE_* macros and start using those instead (Keith Thompson) Use SAFE_() macros for is*() and to*() functions The standard is*() and to*() functions declared in <ctype.h> have undefined behavior for negative arguments other than EOF. If plain char is signed, passing an unchecked value from argv for from user input to one of these functions has undefined behavior. Solution: Add SAFE_*() macros that cast the argument to unsigned char. Most implementations behave sanely for negative arguments, and most character values in practice are non-negative, but it's still best to avoid undefined behavior. The change from #13347 has been omitted, as this has already been separately fixed in commit ac709e2fc0db6d31abb7da96f743c40956b60c3a (v9.0.2054) fixes: #13332 closes: #13347 Signed-off-by: Keith Thompson <Keith.S.Thompson@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-12-21patch 9.0.2184: Vim9: inconsistent :type/:class messagesv9.0.2184Ernie Rael
Problem: Vim9: inconsistent :type/:class messages Solution: Update the Messages (Ernie Rael) closes: #13706 Signed-off-by: Ernie Rael <errael@raelity.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-12-19patch 9.0.2180: POSIX function name in exarg causes issuesv9.0.2180Zoltan Arpadffy
Problem: POSIX function name in exarg struct causes issues on OpenVMS Solution: Rename getline member in exarg struct to ea_getline, remove isinf() workaround for VMS There are compilers that do not treat well POSIX functions - like getline - usage in the structs. Older VMS compilers could digest this... but the newer OpenVMS compilers ( like VSI C x86-64 X7.4-843 (GEM 50XB9) ) cannot deal with these structs. This could be limited to getline() that is defined via getdelim() and might not affect all POSIX functions in general - but avoiding POSIX function names usage in the structs is a "safe side" practice without compromising the functionality or the code readability. The previous OpenVMS X86 port used a workaround limiting the compiler capabilities using __CRTL_VER_OVERRIDE=80400000 In order to make the OpenVMS port future proof, this pull request proposes a possible solution. closes: #13704 Signed-off-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-12-18patch 9.0.2174: Vim9: segfault when assigning to typev9.0.2174Ernie Rael
Problem: Vim9: segfault when assigning to type Solution: do not clear typeval, add missing patch number closes: #13714 closes: #13715 Signed-off-by: Ernie Rael <errael@raelity.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-12-11patch 9.0.2156: Vim9: can use typealias in assignmentv9.0.2156Ernie Rael
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.
2023-10-28patch 9.0.2078: several problems with type aliasesv9.0.2078Yegappan Lakshmanan
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 #13438 closes #13441 Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2023-10-27patch 9.0.2076: Vim9: No support for type aliasesv9.0.2076Yegappan Lakshmanan
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>
2023-10-05patch 9.0.1986: Vim9: accepting type-annotationsv9.0.1986Yegappan Lakshmanan
Problem: Vim9: accepting type-annotations Solution: Reject type annotations outside of declarations. closes: #13267 closes: #13283 Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
2023-10-04patch 9.0.1982: vim9: clean up from v9.0.1955v9.0.1982Ernie Rael
Problem: vim9: clean up from v9.0.1955 Solution: Fix a few remaining issues, improve error message - Use `cl_exec`, the executing class, to check permissions in `get_lval()`. - Handle lockvar of script variable from class. - Add 'in class "Xxx"' to e_cannot_access_private_variable_str. closes: #13222 Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Ernie Rael <errael@raelity.com>
2023-09-29patch 9.0.1955: Vim9: lockvar issues with objects/classesv9.0.1955Ernie Rael
Problem: Vim9: lockvar issues with objects/classes Solution: fix `get_lhs()` object/class access and avoid `SEGV`, make error messages more accurate. - `get_lval()` detects/returns object/class access - `compile_lock_unlock()` generate code for bare static and obj_arg access - `do_lock_var()` check lval for `ll_object`/`ll_class` and fail if so. Details: - Add `ll_object`/`ll_class`/`ll_oi` to `lval_T`. - Add `lockunlock_T` to `isn_T` for `is_arg` to specify handling of `lval_root` in `get_lval()`. - In `get_lval()`, fill in `ll_object`/`ll_class`/`ll_oi` as needed; when no `[idx] or .key`, check lval_root on the way out. - In `do_lock_var()` check for `ll_object`/`ll_class`; also bullet proof ll_dict case and give `Dictionay required` if problem. (not needed to avoid lockvar crash anymore) - In `compile_lock_unlock()` compile for the class variable and func arg cases. closes: #13174 Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Ernie Rael <errael@raelity.com>
2023-09-24patch 9.0.1933: Can change the type of a v: variable using if_luav9.0.1933zeertzjq
Problem: Can change the type of a v: variable using if_lua. Solution: Add additional handling of v: variables like :let. closes: #13161 Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2023-08-20patch 9.0.1776: No support for stable Python 3 ABIv9.0.1776Yee Cheng Chin
Problem: No support for stable Python 3 ABI Solution: Support Python 3 stable ABI Commits: 1) Support Python 3 stable ABI to allow mixed version interoperatbility Vim currently supports embedding Python for use with plugins, and the "dynamic" linking option allows the user to specify a locally installed version of Python by setting `pythonthreedll`. However, one caveat is that the Python 3 libs are not binary compatible across minor versions, and mixing versions can potentially be dangerous (e.g. let's say Vim was linked against the Python 3.10 SDK, but the user sets `pythonthreedll` to a 3.11 lib). Usually, nothing bad happens, but in theory this could lead to crashes, memory corruption, and other unpredictable behaviors. It's also difficult for the user to tell something is wrong because Vim has no way of reporting what Python 3 version Vim was linked with. For Vim installed via a package manager, this usually isn't an issue because all the dependencies would already be figured out. For prebuilt Vim binaries like MacVim (my motivation for working on this), AppImage, and Win32 installer this could potentially be an issue as usually a single binary is distributed. This is more tricky when a new Python version is released, as there's a chicken-and-egg issue with deciding what Python version to build against and hard to keep in sync when a new Python version just drops and we have a mix of users of different Python versions, and a user just blindly upgrading to a new Python could lead to bad interactions with Vim. Python 3 does have a solution for this problem: stable ABI / limited API (see https://docs.python.org/3/c-api/stable.html). The C SDK limits the API to a set of functions that are promised to be stable across versions. This pull request adds an ifdef config that allows us to turn it on when building Vim. Vim binaries built with this option should be safe to freely link with any Python 3 libraies without having the constraint of having to use the same minor version. Note: Python 2 has no such concept and this doesn't change how Python 2 integration works (not that there is going to be a new version of Python 2 that would cause compatibility issues in the future anyway). --- Technical details: ====== The stable ABI can be accessed when we compile with the Python 3 limited API (by defining `Py_LIMITED_API`). The Python 3 code (in `if_python3.c` and `if_py_both.h`) would now handle this and switch to limited API mode. Without it set, Vim will still use the full API as before so this is an opt-in change. The main difference is that `PyType_Object` is now an opaque struct that we can't directly create "static types" out of, and we have to create type objects as "heap types" instead. This is because the struct is not stable and changes from version to version (e.g. 3.8 added a `tp_vectorcall` field to it). I had to change all the types to be allocated on the heap instead with just a pointer to them. Other functions are also simply missing in limited API, or they are introduced too late (e.g. `PyUnicode_AsUTF8AndSize` in 3.10) to it that we need some other ways to do the same thing, so I had to abstract a few things into macros, and sometimes re-implement functions like `PyObject_NEW`. One caveat is that in limited API, `OutputType` (used for replacing `sys.stdout`) no longer inherits from `PyStdPrinter_Type` which I don't think has any real issue other than minor differences in how they convert to a string and missing a couple functions like `mode()` and `fileno()`. Also fixed an existing bug where `tp_basicsize` was set incorrectly for `BufferObject`, `TabListObject, `WinListObject`. Technically, there could be a small performance drop, there is a little more indirection with accessing type objects, and some APIs like `PyUnicode_AsUTF8AndSize` are missing, but in practice I didn't see any difference, and any well-written Python plugin should try to avoid excessing callbacks to the `vim` module in Python anyway. I only tested limited API mode down to Python 3.7, which seemes to compile and work fine. I haven't tried earlier Python versions. 2) Fix PyIter_Check on older Python vers / type##Ptr unused warning For PyIter_Check, older versions exposed them as either macros (used in full API), or a function (for use in limited API). A previous change exposed PyIter_Check to the dynamic build because Python just moved it to function-only in 3.10 anyway. Because of that, just make sure we always grab the function in dynamic builds in earlier versions since that's what Python eventually did anyway. 3) Move Py_LIMITED_API define to configure script Can now use --with-python-stable-abi flag to customize what stable ABI version to target. Can also use an env var to do so as well. 4) Show +python/dyn-stable in :version, and allow has() feature query Not sure if the "/dyn-stable" suffix would break things, or whether we should do it another way. Or just don't show it in version and rely on has() feature checking. 5) Documentation first draft. Still need to implement v:python3_version 6) Fix PyIter_Check build breaks when compiling against Python 3.8 7) Add CI coverage stable ABI on Linux/Windows / make configurable on Windows This adds configurable options for Windows make files (both MinGW and MSVC). CI will also now exercise both traditional full API and stable ABI for Linux and Windows in the matrix for coverage. Also added a "dynamic" option to Linux matrix as a drive-by change to make other scripting languages like Ruby / Perl testable under both static and dynamic builds. 8) Fix inaccuracy in Windows docs Python's own docs are confusing but you don't actually want to use `python3.dll` for the dynamic linkage. 9) Add generated autoconf file 10) Add v:python3_version support This variable indicates the version of Python3 that Vim was built against (PY_VERSION_HEX), and will be useful to check whether the Python library you are loading in dynamically actually fits it. When built with stable ABI, it will be the limited ABI version instead (`Py_LIMITED_API`), which indicates the minimum version of Python 3 the user should have, rather than the exact match. When stable ABI is used, we won't be exposing PY_VERSION_HEX in this var because it just doesn't seem necessary to do so (the whole point of stable ABI is the promise that it will work across versions), and I don't want to confuse the user with too many variables. Also, cleaned up some documentation, and added help tags. 11) Fix Python 3.7 compat issues Fix a couple issues when using limited API < 3.8 - Crash on exit: In Python 3.7, if a heap-allocated type is destroyed before all instances are, it would cause a crash later. This happens when we destroyed `OptionsType` before calling `Py_Finalize` when using the limited API. To make it worse, later versions changed the semantics and now each instance has a strong reference to its own type and the recommendation has changed to have each instance de-ref its own type and have its type in GC traversal. To avoid dealing with these cross-version variations, we just don't free the heap type. They are static types in non-limited-API anyway and are designed to last through the entirety of the app, and we also don't restart the Python runtime and therefore do not need it to have absolutely 0 leaks. See: - https://docs.python.org/3/whatsnew/3.8.html#changes-in-the-c-api - https://docs.python.org/3/whatsnew/3.9.html#changes-in-the-c-api - PyIter_Check: This function is not provided in limited APIs older than 3.8. Previously I was trying to mock it out using manual PyType_GetSlot() but it was brittle and also does not actually work properly for static types (it will generate a Python error). Just return false. It does mean using limited API < 3.8 is not recommended as you lose the functionality to handle iterators, but from playing with plugins I couldn't find it to be an issue. - Fix loading of PyIter_Check so it will be done when limited API < 3.8. Otherwise loading a 3.7 Python lib will fail even if limited API was specified to use it. 12) Make sure to only load `PyUnicode_AsUTF8AndSize` in needed in limited API We don't use this function unless limited API >= 3.10, but we were loading it regardless. Usually it's ok in Unix-like systems where Python just has a single lib that we load from, but in Windows where there is a separate python3.dll this would not work as the symbol would not have been exposed in this more limited DLL file. This makes it much clearer under what condition is this function needed. closes: #12032 Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
2023-08-19patch 9.0.1741: No type checking in interfacesv9.0.1741LemonBoy
Problem: No type checking in interfaces Solution: Implement member type check in vim9 interfaces Most of the code is a small refactoring to allow the use of a where_T for signaling the type mismatch, the type checking itself is pretty simple. Improve where_T error reports Let the caller explicitly define the kind of location it's referring to and free the WT_ARGUMENT enum from its catch-all role. Implement type checking for interface methods Follows closely the logic used for type-checking the members. closes: #12844 Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: LemonBoy <thatlemon@gmail.com>
2023-06-14patch 9.0.1631: passing wrong variable type to option gives multiple errorsv9.0.1631zeertzjq
Problem: Passing a wrong variable type to an option gives multiple errors. Solution: Bail out early on failure. (closes #12504)
2023-06-05patch 9.0.1611: v:maxcol can be changed in a :for loopv9.0.1611Bram Moolenaar
Problem: v:maxcol can be changed in a :for loop. Solution: Check for read-only loop variable. (closes #12470)
2023-05-24patch 9.0.1576: users may not know what to do with an internal errorv9.0.1576Bram Moolenaar
Problem: Users may not know what to do with an internal error. Solution: Add a translated message with instructions.
2023-04-12patch 9.0.1447: condition is always truev9.0.1447zeertzjq
Problem: Condition is always true. Solution: Remove the useless condition. (closes #12253)
2023-03-07patch 9.0.1390: FOR_ALL_ macros are defined in an unexpected filev9.0.1390Yegappan Lakshmanan
Problem: FOR_ALL_ macros are defined in an unexpected file. Solution: Move FOR_ALL_ macros to macros.h. Add FOR_ALL_HASHTAB_ITEMS. (Yegappan Lakshmanan, closes #12109)
2023-02-01patch 9.0.1271: using sizeof() and subtract array size is trickyv9.0.1271zeertzjq
Problem: Using sizeof() and subtract array size is tricky. Solution: Use offsetof() instead. (closes #11926)
2023-01-30patch 9.0.1266: error for space before ": type" is inconsistentv9.0.1266Bram Moolenaar
Problem: Error for space before ": type" is inconsistent. Solution: Give E1059 in more places. (closes #11868)
2023-01-12patch 9.0.1188: return value of type() for class and object unclearv9.0.1188Bram Moolenaar
Problem: Return value of type() for class and object unclear. Solution: Add v:t_object and v:t_class.
2023-01-12patch 9.0.1186: imported class does not work when used twice in a linev9.0.1186Bram Moolenaar
Problem: Imported class does not work when used twice in a line. Solution: Fix the type parsing.
2023-01-12patch 9.0.1185: using class from imported script not testedv9.0.1185Bram Moolenaar
Problem: Using class from imported script not tested. Solution: Add tests. Implement what is missing.
2023-01-06patch 9.0.1152: class "implements" argument not implementedv9.0.1152Bram Moolenaar
Problem: Class "implements" argument not implemented. Solution: Implement "implements" argument. Add basic checks for when a class implements an interface.
2023-01-03patch 9.0.1137: some conditions are always falsev9.0.1137zeertzjq
Problem: Some conditions are always false. Solution: Remove the useless conditions. (closes #11776)
2023-01-02patch 9.0.1133: error message names do not match the itemsv9.0.1133Bram Moolenaar
Problem: Error message names do not match the items. Solution: Add "_str" when the text contains "%s".
2023-01-02patch 9.0.1132: code is indented more than neededv9.0.1132Yegappan Lakshmanan
Problem: Code is indented more than needed. Solution: Use an early return to reduce indentation. (Yegappan Lakshmanan, closes #11769)
2022-12-08patch 9.0.1031: Vim9 class is not implemented yetv9.0.1031Bram Moolenaar
Problem: Vim9 class is not implemented yet. Solution: Add very basic class support.
2022-12-02patch 9.0.0990: callback name argument is changed by setqflist()v9.0.0990Bram Moolenaar
Problem: Callback name argument is changed by setqflist(). Solution: Use the expanded function name for the callback, do not store it in the argument. (closes #11653)
2022-11-28patch 9.0.0965: using one window for executing autocommands is insufficientv9.0.0965Bram Moolenaar
Problem: Using one window for executing autocommands is insufficient. Solution: Use up to five windows for executing autocommands.
2022-11-25patch 9.0.0949: crash when unletting a variable while listing variablesv9.0.0949Bram Moolenaar
Problem: Crash when unletting a variable while listing variables. Solution: Disallow changing a hashtable while going over the entries. (closes #11435)
2022-11-16patch 9.0.0890: no test for what patch 9.0.0827 fixesv9.0.0890Bram Moolenaar
Problem: No test for what patch 9.0.0827 fixes. Solution: Add a test (still doesn't fail when fix is reverted).
2022-10-13patch 9.0.0744: in script in autoload dir exported variable is not foundv9.0.0744Bram Moolenaar
Problem: In script in autoload dir exported variable is not found. (Doug Kearns) Solution: Find the variable with the "script#" prefix. (closes #11361)
2022-10-12patch 9.0.0732: no check for white space before and after "=<<"v9.0.0732Bram Moolenaar
Problem: No check for white space before and after "=<<". (Doug Kearns) Solution: Check for white space in Vim9 script. (closes #11351)
2022-10-01patch 9.0.0634: evaluating "expr" options has more overhead than neededv9.0.0634Bram Moolenaar
Problem: Evaluating "expr" options has more overhead than needed. Solution: Use call_simple_func() for 'foldtext', 'includeexpr', 'printexpr', "expr" of 'spellsuggest', 'diffexpr', 'patchexpr', 'balloonexpr', 'formatexpr', 'indentexpr' and 'charconvert'.
2022-09-21patch 9.0.0535: closure gets wrong value in for loop with two loop variablesv9.0.0535Bram Moolenaar
Problem: Closure gets wrong value in for loop with two loop variables. Solution: Correctly compute the number of loop variables to clear.
2022-09-14patch 9.0.0460: loop variable can't be foundv9.0.0460Bram Moolenaar
Problem: Loop variable can't be found. Solution: Adjust block_id of the loop variable each round.
2022-09-11patch 9.0.0444: trying to declare g:variable gives confusing errorv9.0.0444Bram Moolenaar
Problem: Trying to declare g:variable gives confusing error. Solution: Give a better error message. (closes #11108)
2022-09-06patch 9.0.0398: members of funccall_T are inconsistently namedv9.0.0398Bram Moolenaar
Problem: Members of funccall_T are inconsistently named. Solution: Use the "fc_" prefix for all members.
2022-09-03patch 9.0.0364: clang static analyzer gives warningsv9.0.0364Yegappan Lakshmanan
Problem: Clang static analyzer gives warnings. Solution: Avoid the warnings. (Yegappan Lakshmanan, closes #11043)
2022-09-02patch 9.0.0355: check for uppercase char in autoload name is wrongv9.0.0355thinca
Problem: Check for uppercase char in autoload name is wrong, it checks the name of the script. Solution: Remove the check. (closes #11031)
2022-08-24patch 9.0.0253: a symlink to an autoload script results in two entriesv9.0.0253Bram Moolenaar
Problem: A symlink to an autoload script results in two entries in the list of scripts, items expected in one are actually in the other. Solution: Have one script item refer to the actually sourced one. (closes #10960)
2022-08-14patch 9.0.0206: redraw flags are not named specificallyv9.0.0206Bram Moolenaar
Problem: Redraw flags are not named specifically. Solution: Prefix "UPD_" to the flags, for UPDate_screen().
2022-07-27patch 9.0.0092: plugins cannot change v:completed_itemv9.0.0092Shougo Matsushita
Problem: Plugins cannot change v:completed_item. Solution: Make v:completed_item writeable. (Shougo Matsushita, closes #10801)
2022-07-27patch 9.0.0090: no error when assigning bool to a string optionv9.0.0090Bram Moolenaar
Problem: No error when assigning bool to a string option with setwinvar(). Solution: Give an error (closes #10766)