Problem: unused function typval_compare_class() and error constants
Solution: remove function typval_compare_class() and ifdef out
unused error constants (Dominique Pellé)
closes: #15299
Signed-off-by: Dominique Pellé <dominique.pelle@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: Can define a class in a function
(Doug Kearns)
Solution: Give an error for a class defined in a function,
slightly reword some public error messages
(Yegappan Lakshmanan)
fixes: #13184fixes: #13326closes: #14537
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Error E877 is not translated (RestorerZ)
Solution: Declare the error with N_ to mark it as translatable, add _()
around the error message in regexp_nfa.c
fixes: #14333
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: E1513 might be confusing
(Christoph Thoma)
Solution: reword error message, fix test to not
depend on the actual message
fixes: #14189
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Internal error or crash when passing invalid position to
getregion().
Solution: Give an error for invalid position (zeertzjq).
closes: #14172
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: can't call internal methods with objects
Solution: Add support for empty(), len() and string() function
calls for objects (Yegappan Lakshmanan)
closes: #14129
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Cannot keep a buffer focused in a window
(Amit Levy)
Solution: Add the 'winfixbuf' window-local option
(Colin Kennedy)
fixes: #6445closes: #13903
Signed-off-by: Colin Kennedy <colinvfx@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: font ligatures don't render correctly in the Win32 GUI-version
of gvim even when set rop=type:directx is used. Setting
guiligatures also doesn't make any difference. This leads to
broken font ligatures when the cursor passes through them. It
does not recover from this, and they remain broken until you
re-render the whole buffer (e.g. by using Ctrl+L).
Solution: the problem is that we only re-draw the current and previous
character in gui_undraw_cursor() and only have the special case
for GTK when it comes to rendering ligatures. So let's enable
gui_adjust_undraw_cursor_for_ligatures() to also happen for
Win32 GUI if guiligatures is setup correctly (all this does is
expand the range of gui_undraw_cursor() with ligature characters).
related: #9181
related: #12901closes: #14084
Signed-off-by: Erik S. V. Jansson <caffeineviking@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Need a diff() Vim script function
Solution: Add the diff() Vim script function using the
xdiff internal diff library, add support for
"unified" and "indices" mode.
(Yegappan Lakshmanan)
fixes: #4241closes: #12321
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Autocmds triggered from opening the cmdwin (in win_split and
do_ecmd) can cause issues such as E199, as the current checks
are insufficient.
Solution: Commands executed from the cmdwin apply to the old curwin/buf,
so they should be kept in a "suspended" state; abort if
they've changed. Also abort if cmdwin/buf was tampered with,
and check that curwin is correct. Try to clean up the cmdwin
buffer (only if hidden and non-current to simplify things; the
same approach is used when closing cmdwin normally), and add a
beep. (Sean Dewar)
It'd be nice to also check that curwin was *really* created by win_split, as
autocommands can change curwin before it returns (so it can't be assumed to be
that of the split); for now, this means that the cmdwin may not be the botwin in
that case, which is probably OK.
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: too vague errors for 'listchars'/'fillchars'
Solution: Include the field name in error message.
(zeertzjq)
related: neovim/neovim#27050
closes: #13877
Co-authored-by: Cole Frankenhoff <cole.nhf@gmail.com>
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Cannot easily get the list of matches
Solution: Add the matchstrlist() and matchbufline() Vim script
functions (Yegappan Lakshmanan)
closes: #13766
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
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-script object/class variable declarations use syntax
that is inconsistent with the rest of the language.
Solution: Use :var to declare object and class variables.
closes: #13670
Signed-off-by: Doug Kearns <dougkearns@gmail.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: 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: Duplicate Netbeans Error Message
Solution: Remove duplicate message
We have 2 error Messages used for the Netbeans interface:
- EXTERN char e_invalid_buffer_identifier_in_close[]
INIT(= N_("E648: Invalid buffer identifier in close"));
- EXTERN char e_invalid_buffer_identifier_in_close_2[]
INIT(= N_("E649: Invalid buffer identifier in close"));
Since the error message is exactly the same, get rid of the second
message.
closes: #13584
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: abstract can be used in interface
Solution: Disallow the use of abstract in an interface
fixes: #13456closes: #13464
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: [security] overflow in :history
Solution: Check that value fits into int
The get_list_range() function, used to parse numbers for the :history
and :clist command internally uses long variables to store the numbers.
However function arguments are integer pointers, which can then
overflow.
Check that the return value from the vim_str2nr() function is not larger
than INT_MAX and if yes, bail out with an error. I guess nobody uses a
cmdline/clist history that needs so many entries... (famous last words).
It is only a moderate vulnerability, so impact should be low.
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: non-consistent error messages
Solution: make error messages more consistent with common structure
Adjust vim9class messages to follow common pattern.
[Variable|Method] "var-or-meth-name" ... class "class-name"
closes: #13391
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: trim(): hard to use default mask (partly revert v9.0.2040)
Solution: use default mask when it is empty
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
Currently, an empty 'mask' will make 'trim()' call return 'text' value
that is passed in unmodified. It is unlikely that someone is using it,
so the chances of scripts being broken by this change are low.
Also, this reverts commit 9.0.2040 (which uses v:none for the default
and requires to use an empty string instead).
closes: #13358
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
Problem: trim(): hard to use default mask
Solution: Use default 'mask' when it is v:none
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
'v:none' is already used to mean "use the default argument value" in
user defined functions. See |none-function_argument| in help.
closes: #13363
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
Problem: Vim9: error message can be more accurate
Solution: Fix the error messages
Fix message for some single use error messages.
closes: #13312
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: strange error number
Solution: change error number,
add doc tag for E1507
closes: #13270
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Christ van Willegen <cvwillegen@gmail.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: xattr: permission-denied errors on write
Solution: ignore those errors
closes: #13246
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Gene C <arch@sapience.com>
Problem: xattr errors not translated
Solution: mark for translation, consistently capitalize
first letter.
closes: #13236
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: No support for writing extended attributes
Solution: Add extended attribute support for linux
It's been a long standing issue, that if you write a file with extended
attributes and backupcopy is set to no, the file will loose the extended
attributes.
So this patch adds support for retrieving the extended attributes and
copying it to the new file. It currently only works on linux, mainly
because I don't know the different APIs for other systems (BSD, MacOSX and
Solaris). On linux, this should be supported since Kernel 2.4 or
something, so this should be pretty safe to use now.
Enable the extended attribute support with normal builds.
I also added it explicitly to the :version output as well as make it
able to check using `:echo has("xattr")`, to have users easily check
that this is available.
In contrast to the similar support for SELINUX and SMACK support (which
also internally uses extended attributes), I have made this a FEAT_XATTR
define, instead of the similar HAVE_XATTR.
Add a test and change CI to include relevant packages so that CI can
test that extended attributes are correctly written.
closes: #306closes: #13203
Signed-off-by: Christian Brabandt <cb@256bit.org>
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: Misplaced comment in errors.h
Solution: Move it up
closes: #13218
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ken Takata <kentkt@csc.jp>
Problem: Vim9: hard to debug vim9_class errors from CI
Solution: Include the line number in assert_xxx() calls. Include the
entire error message in the tests. Fix the indentation in the
test file. Add tags for new error codes.
closes: #13206
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: error codes spread out
Solution: group them together and reserve 100
more for future use
Reserve 100 error codes for future enhancements to the Vim9 class
support
closes: #13207
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: object variable "this." should only be used in
constructor
Solution: Disallow to this in normal object methods (other than
constructors)
closes: #13152closes: #13212
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: h-east <h.east.727@gmail.com>
Problem: Vim9: missing support for ro-vars in interface
Solution: Support only read-only object variables in an interface,
add additional checks when parsing class definitions.
closes: #13183
cloess: #13184
cloess: #13185.
closes: #13188
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: not consistent error messages
Solution: Make error messages more consistent. Use "variable" for
(object/class) member
closes: #13155
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: RestorerZ <restorer@mail2k.ru>
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: Vim9: not enough info in error message
Solution: Add class name, change member to variable, quote names
closes: #13136
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Vim9: problem calling class method from other class
Solution: Fix this problem, fix readonly object access, update error
messages.
Calling a class method from another method without the class name prefix
doesn't work properly.
A readonly object variable is modifiable outside the class using a
nested object assignment.
Remove the unused E1338 error message.
Update error messages.
closes: #13116
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: Interfaces should not support class methods and
variables
Solution: Make sure interface follow the interface specification
Vim9 interface changes to follow the new interface specification:
1) An interface can have only read-only and read-write instance
variables.
2) An interface can have only public instance methods.
3) An interface cannot have class variables and class methods.
4) An interface cannot have private instance variables and private
instance methods.
5) A interface can extend another interface using "extends". The
sub-interface gets all the variables and methods in the super
interface.
That means:
- Interfaces should not support class methods and variables.
- Adjust error numbers and add additional tests.
- Interface methods can be defined in one of the super classes.
- Interface variables can be defined in one of the super classes.
and instance variables can be repeated in sub interfaces.
- Check the class variable types with the type in interface.
closes: #13100
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: restrict access to static vars and methods
Solution: Class members are accesible only from the class where they are
defined.
Based on the #13004 discussion, the following changes are made:
1) Static variables and methods are accessible only using the class
name and inside the class where they are defined.
2) Static variables and methods can be used without the class name in
the class where they are defined.
3) Static variables of a super class are not copied to the sub class.
4) A sub class can declare a class variable with the same name as the
super class.
5) When a method or member is found during compilation, use more
specific error messages.
This aligns the Vim9 class variable/method implementation with the Dart
implementation.
Also while at it, ignore duplicate class and object methods.
The access level of an object method can however be changed in a
subclass.
For the tests, use the new CheckSourceFailure() function instead of the
CheckScriptFailure() function in the tests.
closes: #13086
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
