Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 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>
|
|
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: 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Problem: Passing a wrong variable type to an option gives multiple errors.
Solution: Bail out early on failure. (closes #12504)
|
|
Problem: v:maxcol can be changed in a :for loop.
Solution: Check for read-only loop variable. (closes #12470)
|
|
Problem: Users may not know what to do with an internal error.
Solution: Add a translated message with instructions.
|
|
Problem: Condition is always true.
Solution: Remove the useless condition. (closes #12253)
|
|
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)
|
|
Problem: Using sizeof() and subtract array size is tricky.
Solution: Use offsetof() instead. (closes #11926)
|
|
Problem: Error for space before ": type" is inconsistent.
Solution: Give E1059 in more places. (closes #11868)
|
|
Problem: Return value of type() for class and object unclear.
Solution: Add v:t_object and v:t_class.
|
|
Problem: Imported class does not work when used twice in a line.
Solution: Fix the type parsing.
|
|
Problem: Using class from imported script not tested.
Solution: Add tests. Implement what is missing.
|
|
Problem: Class "implements" argument not implemented.
Solution: Implement "implements" argument. Add basic checks for when a
class implements an interface.
|
|
Problem: Some conditions are always false.
Solution: Remove the useless conditions. (closes #11776)
|
|
Problem: Error message names do not match the items.
Solution: Add "_str" when the text contains "%s".
|
|
Problem: Code is indented more than needed.
Solution: Use an early return to reduce indentation. (Yegappan Lakshmanan,
closes #11769)
|
|
Problem: Vim9 class is not implemented yet.
Solution: Add very basic class support.
|
|
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)
|
|
Problem: Using one window for executing autocommands is insufficient.
Solution: Use up to five windows for executing autocommands.
|
|
Problem: Crash when unletting a variable while listing variables.
Solution: Disallow changing a hashtable while going over the entries.
(closes #11435)
|
|
Problem: No test for what patch 9.0.0827 fixes.
Solution: Add a test (still doesn't fail when fix is reverted).
|
|
Problem: In script in autoload dir exported variable is not found. (Doug
Kearns)
Solution: Find the variable with the "script#" prefix. (closes #11361)
|
|
Problem: No check for white space before and after "=<<". (Doug Kearns)
Solution: Check for white space in Vim9 script. (closes #11351)
|
|
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'.
|
|
Problem: Closure gets wrong value in for loop with two loop variables.
Solution: Correctly compute the number of loop variables to clear.
|
|
Problem: Loop variable can't be found.
Solution: Adjust block_id of the loop variable each round.
|
|
Problem: Trying to declare g:variable gives confusing error.
Solution: Give a better error message. (closes #11108)
|
|
Problem: Members of funccall_T are inconsistently named.
Solution: Use the "fc_" prefix for all members.
|
|
Problem: Clang static analyzer gives warnings.
Solution: Avoid the warnings. (Yegappan Lakshmanan, closes #11043)
|
|
Problem: Check for uppercase char in autoload name is wrong, it checks the
name of the script.
Solution: Remove the check. (closes #11031)
|
|
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)
|
|
Problem: Redraw flags are not named specifically.
Solution: Prefix "UPD_" to the flags, for UPDate_screen().
|
|
Problem: Plugins cannot change v:completed_item.
Solution: Make v:completed_item writeable. (Shougo Matsushita,
closes #10801)
|
|
Problem: No error when assigning bool to a string option with setwinvar().
Solution: Give an error (closes #10766)
|
|
Problem: Switching window uneccarily when getting buffer options.
Solution: Do not switch window when getting buffer options. (closes #10767)
|