patch 9.0.1956: Custom completion skips orig cmdline if it invokes glob()
Problem: Custom cmdline completion skips original cmdline when pressing
Ctrl-P at first match if completion function invokes glob().
Solution: Move orig_save into struct expand_T.
closes: #13216
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
patch 9.0.1955: Vim9: lockvar issues with objects/classes
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>
patch 9.0.1951: Vim9: hard to debug vim9_class errors from CI
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>
patch 9.0.1948: Vim9: object variable "this." should only be used in constructor
Problem: Vim9: object variable "this." should only be used in
constructor
Solution: Disallow to this in normal object methods (other than
constructors)
closes: #13152
closes: #13212
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: h-east <h.east.727@gmail.com>
Ken Takata [Thu, 28 Sep 2023 19:59:58 +0000 (21:59 +0200)]
patch 9.0.1947: Bash Expansion test fails on Windows/MacOS
Problem: Bash Expansion test fails on Windows/MacOS
Solution: Disable Test_glob_extended_bash for now
This test doesn't work on Windows even if bash can be executed, since
the globstar functionality has only been enabled in Unix builds of Vim
(Commit 9eb1ce531527a7177d16373b0f8689bbcd3d5f73, patch 9.0.1946).
closes: #13205
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Ken Takata <kentkt@csc.jp>
patch 9.0.1946: filename expansion using ** in bash may fail
Problem: filename expansion using ** in bash may fail
Solution: Try to enable the globstar setting
Starting with bash 4.0 it supports extended globbing using the globstar
shell option. This makes matching recursively below a certain directory
using the ** pattern work as expected nowadays. However, we need to
explicitly enable this using the 'shopt -s globstar' bash command.
So let's check the bash environment variable $BASH_VERSINFO (which is
supported since bash 3.0 and conditionally enable the globstar option,
if the major version is at least 4. For older bashs, this at least
shouldn't cause errors (unless one is using really ancient bash 2.X or
something).
patch 9.0.1945: Vim9: missing support for ro-vars in interface
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.
patch 9.0.1939: still a problem when processing LSP RPC requests
Problem: still a problem when processing LSP RPC requests
Solution: When processing async LSP RPC requests, compare sequence
numbers only in response messages
A LSP request message can be sent to the language server either
synchronously (ch_evalexpr) or asynchronously (ch_sendexpr). In both
cases, when looking for response messages by using the sequence number,
LSP requests messages from the language server with the same sequence
number should not be used. Patch 9.0.1927 fixed this issue for
synchronous requests. This PR fixes the issue for asynchronous requests
and adds additional tests.
closes: #13158
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
patch 9.0.1938: multispace wrong when scrolling horizontally
Problem: multispace wrong when scrolling horizontally
Solution: Update position in "multispace" or "leadmultispace" also in
skipped chars. Reorder conditions to be more consistent.
closes: #13145
closes: #13147
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
patch 9.0.1931: make test_compilers fails on ubuntu
Problem: make test_compilers fails on ubuntu
Solution: set LC_ALL=C
fix: make test_compiler failed on xubuntu 22.04.3
Problem: 'make test_compiler' failed on Linux xubuntu 22.04.3 but
succeeded on e.g. macOS. To reproduce:
```
$ ./configure --with-features=huge --enable-gui=no --enable-perlinterp=yes
$ make -j12
$ cd vim/src/testdir
$ make test_compiler
...snip...
Found errors in Test_compiler():
command line..script /home/dope/sb/vim/src/testdir/runtest.vim[601]..function RunTheTest[54]..Test_compiler line 24: command did not fail: clist
command line..script /home/dope/sb/vim/src/testdir/runtest.vim[601]..function RunTheTest[54]..Test_compiler line 30: Pattern '\\n \\d\\+ Xfoo.pl:3: Global symbol "$foo" requires explicit package name' does not match '\n19 Xfoo.pl:3: Global symbol "$foo" requires explicit package name (did you forget to declare "my $foo"?)'
make: *** [Makefile:70: test_compiler] Error 1
```
Solution: set `LC_ALL` to "C" in `Test_compiler()`
closes: #13173
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Dominique Pellé <dominique.pelle@tomtom.com>
Problem: compiler warnings with clang-17
Solution: Fix function prototypes and function pointer
fix: clang compilation warnings with -Wstrict-prototypes
Change fixes this kind of compilation warnings with clang:
```
proto/if_python3.pro:13:20: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
13 | int python3_version();
| ^
| void
```
closes: #13166
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Dominique Pellé <dominique.pelle@tomtom.com>
patch 9.0.1919: Wrong curswant when clicking on empty line or with vsplits
Problem: Wrong curswant when clicking on empty line or with vsplits.
Solution: Don't check for ScreenCols[] before the start of the window
and handle empty line properly.
closes: #13132
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: zeertzjq <zeertzjq@outlook.com>
patch 9.0.1915: r_CTRL-C works differently in visual mode
Problem: r_CTRL-C works differently in visual mode
Solution: Make r_CTRL-C behave consistent in visual mode
in terminal and Windows GUI
in visual mode, r CTRL-C behaves strange in Unix like environments. It
seems to end visual mode, but still is waiting for few more chars,
however it never seems to replace it by any characters and eventually
just returns back into normal mode.
In contrast in Windows GUI mode, r_CTRL-C replaces in the selected area
all characters by a literal CTRL-C.
Not sure why it behaves like this. It seems in the Windows GUI, got_int
is not set and therefore behaves as if any other normal character has
been pressed.
So remove the special casing of what happens when got_int is set and
make it always behave like in Windows GUI mode. Add a test to verify it
always behaves like replacing in the selected area each selected
character by a literal CTRL-C.
patch 9.0.1914: Vim9: few issues when accessing object members
Problem: Vim9: few issues when accessing object members
Solution: When calling an object method, check for null object.
Accessing a Dict object member doesn't work.
closes: #13119
closes: #13123
closes: #13124
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Cirrus-CI running out of credits
Solution: disable Cirrus-CI for now
We are running out of credits for Cirrus CI already at the middle of the
month and unfortunately this means our CI now consistently fails. This
all hapens because cirrus ci is not enforcing the free-tier limits (see also
https://cirrus-ci.org/blog/2023/07/17/limiting-free-usage-of-cirrus-ci/).
Perhaps at the beginning of the next month we can revisit and
enable just a build without testing it. Hopefully this is won't take
too many credits and we can at least verify that building works.
patch 9.0.1910: Mac OS X: missing sound support on older versions
Problem: Mac OS X: missing sound support on older versions
Solution: Check Macro MAC_OS_X_VERSION_MIN_REQUIRED
Extend guard for sound support on OS X
Fixes build on legacy versions where required coreaudio functionality
may not be available. NSSoundDelegate apparently was introduced in Snow
Leopard yet the build breaks on it. Guarding off enabling sound support
to El Capitan as that's the next version I had access to for testing (it
may work on earlier versions)
https://developer.apple.com/documentation/appkit/nssounddelegate Vim
builds on OS X Tiger 10.4 and newer with this change.
closes: #13115
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Sevan Janiyan <venture37@geeklan.co.uk>
patch 9.0.1908: undefined behaviour upper/lower function ptrs
Problem: undefined behaviour upper/lower function ptrs
Solution: Fix UBSAN error in regexp and simplify upper/lowercase
modifier code
The implementation of \u / \U / \l / \L modifiers in the substitute
command relies on remembering the state by setting function pointers on
func_all/func_one in the code. The code signature of `fptr_T` is
supposed to return void* (due to C function signatures not being able to
return itself due to type recursion), and the definition of the
functions (e.g. to_Upper) didn't follow this rule, and so the code tries
to cast functions of different signatures, resulting in undefined
behavior error under UBSAN in Clang 17. See #12745.
We could just fix `do_Upper`/etc to just return void*, which would fix
the problem. However, these functions actually do not need to return
anything at all. It used to be the case that there was only one pointer
"func" to store the pointer, which is why the function needs to either
return itself or NULL to indicate whether it's a one time or ongoing
modification. However, c2c355df6f094cdb9e599fd395a78c14486ec697
(7.3.873) already made that obsolete by introducing `func_one` and
`func_all` to store one-time and ongoing operations separately, so these
functions don't actually need to return anything anymore because it's
implicit whether it's a one-time or ongoing operation. Simplify the code
to reflect that.
closes: #13117
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
patch 9.0.1906: Vim9: Interfaces should not support class methods and variables
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: FEAT_FLOAT no longer defined
Solution: Remove last existing FEAT_FLOAT ifdefs in
message_test
Remove FEAT_FLOAT as that should always be true
FEAT_FLOAT has been removed in v9.0.0491 (73e28dcc6125f616cf1f2) but
unfortunately, it was forgotten to remove it from message_test.c. So
let's remove the last mentioned ifdefs which are now unused.
closes: #13106
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: dundargoc <gocdundar@gmail.com>
patch 9.0.1904: Cirrus-CI fails because we have used all credits
Problem: Cirrus-CI fails because we have used all credits
Solution: Remove FreeBSD 13.1 and MacOS M1
Cirrus CI has started introducing monthly limits. Vim has exceeded the
monthly limit which means our CI unfortunately starts to fail. So let's
remove some CI tasks, so that in the future we won't run out of credits
so fast.
closes: #13108
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: dundargoc <gocdundar@gmail.com>
runtime(man): Man plugin does not respect 'gdefault'
Fix the issue introduced by #12557. `:substitute` commands in plugins
need to take into account whether `gdefault` is set or not because
that depends on the user.
patch 9.0.1902: Vim9: Coverity complains about dead code
Problem: Vim9: Coverity complains about dead code
Solution: Copy only object methods from the super class
to a subclass when extending a class. Fix
Coverity warning.
closes: #13103
Signed-off-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
patch 9.0.1899: potential buffer overflow in PBYTE macro
Problem: potential buffer overflow in PBYTE macro
Solution: Check returned memline length
closes: #13083
the PBYTE macro is used to put byte c at a position lp of the returned
memline. However, in case of unexpected errors ml_get_buf() may return
either "???" or an empty line in which case it is quite likely that we
are causing a buffer overrun.
Therefore, switch the macro PBYTE (which is only used in ops.c anyhow)
to a function, that verifies that we will only try to access within the
given length of the buffer.
Also, since the macro is only used in ops.c, move the definition from
macros.h to ops.c
patch 9.0.1898: Vim9: restrict access to static vars
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>
runtime(help): Updated documentation on editorconfig
Add a small section about the distributed Editorconfig plugin at :h
usr_05.txt just below the matchit plugin. While editing that help
document, also add a bit of more documentation about standard plugins
and local help file additions.
Regenerate $VIMRUNTIME/doc/tags file with all the new tags from the rust
runtime files.
While at it, update the Editorconfig help page (and re-generate the
helptags file).
patch 9.0.1897: Vim9: confusing error with .= in compiled functions
Problem: Vim9: confusing error with .= in compiled functions
Solution: Check in error condition, if .= was attempted and in that case
give a different error message.
Emil Ejbyfeldt [Sun, 10 Sep 2023 16:16:51 +0000 (18:16 +0200)]
runtime(scala): Fix Scala highlighting string literal as type param (#13070)
Since https://docs.scala-lang.org/sips/42.type.html which is implemented
in Scala 2.13 and in Scala 3 it possible to use string literals as
singleton types. So code like
```
someFunc["abc"]
```
is valid. Currently this code is not hightlighted correctly and worse if
there is an unclosed `(` in the string it breaks the formating in the
rest of the file.
I also submitted this patch to the mentioned project for this runtime
file: https://github.com/derekwyatt/vim-scala/pull/173 But there are no
commits there over the last 2 years and no response in the week since I
created it. Also the last change to the Scala syntax file:
https://github.com/vim/vim/pull/9594 is yet to be backported to that
repo. Therefore I am opening this PR as well to get some feedback on how
to proceed to get this fixed.
projects / thirdparty / vim.git / log
