Problem: regexp: max \U and \%U value is limited by INT_MAX but gives a
confusing error message (related: v8.1.0985).
Solution: give a better error message when the value reaches INT_MAX
When searching Vim allows to get up to 8 hex characters using the /\V
and /\%V regex atoms. However, when using "/\UFFFFFFFF" the code point is
already above what an integer variable can hold, which is 2,147,483,647.
Since patch v8.1.0985, Vim already limited the max codepoint to INT_MAX
(otherwise it caused a crash in the nfa regex engine), but instead of
error'ing out it silently fell back to parse the number as a backslash
value and not as a codepoint value and as such this "/[\UFFFFFFFF]" will
happily find a "\" or an literal "F". And this "/[\d127-\UFFFFFFFF]"
will error out as "reverse range in character class).
Interestingly, the max Unicode codepoint value is U+10FFFF which still
fits into an ordinary integer value, which means, that we don't even
need to parse 8 hex characters, but 6 should have been enough.
However, let's not limit Vim to search for only max 6 hex characters
(which would be a backward incompatible change), but instead allow all 8
characters and only if the codepoint reaches INT_MAX, give a more
precise error message (about what the max unicode codepoint value is).
This allows to search for "[\U7FFFFFFE]" (will likely return "E486
Pattern not found") and "[/\U7FFFFFF]" now errors "E1517: Value too
large, max Unicode codepoint is U+10FFFF".
While this change is straight forward on architectures where long is 8
bytes, this is not so simple on Windows or 32bit architectures where long
is 4 bytes (and therefore the test fails there). To account for that,
let's make use of the vimlong_T number type and make a few corresponding
changes in the regex engine code and cast the value to the expected data
type. This however may not work correctly on systems that doesn't have
the long long datatype (e.g. OpenVMS) and probably the test will fail
there.
fixes: vim/vim#16949closes: vim/vim#16994f2b16986a1
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: read/write shada function logic was skipped entirely if it was
detected the shadafile option was set to 'NONE'.
Solution: The filename is now always resolved. When the shadafile option
is set to 'NONE' AND no filename was passed, the filename resolves to an
empty string, which causes the read/write functions to return.
Regardless of whether the option is set to 'NONE', when a filename is
explicitly passed, it gets resolved and the read/write logic is
accessed.
Problem: Wrong patlen value in ex_substitute() (after 9.1.0426).
Solution: Compute patlen after finding end separator.
(zeertzjq)
Add a more explicit test. The test already passes as the only case
where a overlarge patlen value matters was fixed by patch 9.1.0689.
closes: vim/vim#15565d1c8d2de4b
Problem: Too many delete() calls in tests.
Solution: Use deferred delete where possible.
56564964e6
This includes all changes expect changes in test_startup.vim.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: CurSearch highlight is often wrong.
Solution: Remember the last highlighted position and redraw when needed.
368137aa52
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Tests using term_wait() can still be flaky.
Solution: Increase the wait time when rerunning a test. (James McCoy,
closesvim/vim#5899) Halve the initial times to make tests run faster
when there is no rerun.
6a2c5a7dd5
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Some lines of code not covered by tests.
Solution: Add a few more test cases. (Dominique Pellé, closesvim/vim#9453)
8bfa0eb863
Co-authored-by: Dominique Pelle <dominique.pelle@gmail.com>
Problem: incsearch test not sufficient (after 9.0.1691)
Solution: add an additional test
73b8209266
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
Problem: Vim9: builtin function arguments not checked at compile time.
Solution: Add more type checks. (Yegappan Lakshmanan, closesvim/vim#8539)
5b73992d8f
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
