In order to re-order marks according to the :move command, do_move()
uses mark_adjust() in a non-standard manner. The non-standard action is
that it moves some marks *past* other marks. This doesn't matter for
marks, but mark_adjust() calls foldMarkAdjust() which simply changes
fold starts and lengths and doesn't have enough information to know that
other folds have to be checked and reordered.
The array of folds for each window are assumed to be in order of
increasing line number, and if this gets broken some folds can get
"lost".
There has been a previous patch to avoid this problem by deleting and
recalculating all folds in the window, but this comes at the cost of
closing all folds when executing :move, and doesn't cover the case of
manual folds.
This patch adds a new function foldMoveRange() specifically for the
:move command that handles reordering folds as well as simply moving
them. Additionally, we allow calling mark_adjust_nofold() that does the
same as mark_adjust() but doesn't affect any fold array.
Calling mark_adjust_nofold() should be done in the same manner as
calling mark_adjust(), but according changes to the fold arrays must be
done seperately by the calling function.
vim-patch:8.0.0457
vim-patch:8.0.0459
vim-patch:8.0.0461
vim-patch:8.0.0465
Patch-by: oni-link <knil.ino@gmail.com>
Closes#6203https://s3.amazonaws.com/archive.travis-ci.org/jobs/206794197/log.txt
References #3161
[ RUN ] ...d/neovim/neovim/test/functional/terminal/buffer_spec.lua @ 199: terminal buffer term_close() use-after-free #4393
./test/functional/helpers.lua:187: attempt to perform arithmetic on local 'written' (a nil value)
stack traceback:
./test/functional/helpers.lua:187: in function 'nvim_feed'
./test/functional/helpers.lua:329: in function 'execute'
...d/neovim/neovim/test/functional/terminal/buffer_spec.lua:206: in function <...d/neovim/neovim/test/functional/terminal/buffer_spec.lua:199>
[ ERROR ] ...d/neovim/neovim/test/functional/terminal/buffer_spec.lua @ 199: terminal buffer term_close() use-after-free #4393 (199.47 ms)
==================== File /home/travis/build/neovim/neovim/build/log/ubsan.15466 ====================
= =================================================================
= ==15466==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000029101 at pc 0x000000ea7ba0 bp 0x7ffd5bb628c0 sp 0x7ffd5bb628b8
= READ of size 1 at 0x621000029101 thread T0
= #0 0xea7b9f in utf_head_off /home/travis/build/neovim/neovim/src/nvim/mbyte.c:1637:7
= #1 0xeaaf53 in mb_adjustpos /home/travis/build/neovim/neovim/src/nvim/mbyte.c:1840:16
= #2 0xeaab48 in mb_adjust_cursor /home/travis/build/neovim/neovim/src/nvim/mbyte.c:1825:3
= #3 0x11000d0 in normal_finish_command /home/travis/build/neovim/neovim/src/nvim/normal.c:928:5
= #4 0x1077df1 in normal_execute /home/travis/build/neovim/neovim/src/nvim/normal.c:1147:3
= #5 0x16ff943 in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:58:26
= #6 0x102d8db in normal_enter /home/travis/build/neovim/neovim/src/nvim/normal.c:463:3
= #7 0xdf3398 in main /home/travis/build/neovim/neovim/src/nvim/main.c:540:3
= #8 0x2b973e8b4f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
= #9 0x447445 in _start (/home/travis/build/neovim/neovim/build/bin/nvim+0x447445)
=
= 0x621000029101 is located 1 bytes to the right of 4096-byte region [0x621000028100,0x621000029100)
= allocated by thread T0 here:
= #0 0x4f17b8 in malloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x4f17b8)
= #1 0xf1f374 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:84:15
= #2 0xf1f534 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:118:15
= #3 0xebe6a8 in mf_alloc_bhdr /home/travis/build/neovim/neovim/src/nvim/memfile.c:646:17
= #4 0xebc394 in mf_new /home/travis/build/neovim/neovim/src/nvim/memfile.c:297:12
= #5 0xed1368 in ml_new_data /home/travis/build/neovim/neovim/src/nvim/memline.c:2704:16
= #6 0xece6ab in ml_open /home/travis/build/neovim/neovim/src/nvim/memline.c:349:8
= #7 0x6438ad in open_buffer /home/travis/build/neovim/neovim/src/nvim/buffer.c:109:7
= #8 0xa6ec8d in do_ecmd /home/travis/build/neovim/neovim/src/nvim/ex_cmds.c:2489:24
= #9 0xb5a0f9 in do_exedit /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:6723:9
= #10 0xb791f8 in ex_edit /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:6651:3
= #11 0xb28b43 in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2198:5
= #12 0xb077a7 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:601:20
= #13 0x10905db in nv_colon /home/travis/build/neovim/neovim/src/nvim/normal.c:4495:18
= #14 0x1077de8 in normal_execute /home/travis/build/neovim/neovim/src/nvim/normal.c:1144:3
= #15 0x16ff943 in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:58:26
= #16 0x102d8db in normal_enter /home/travis/build/neovim/neovim/src/nvim/normal.c:463:3
= #17 0xdf3398 in main /home/travis/build/neovim/neovim/src/nvim/main.c:540:3
= #18 0x2b973e8b4f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
=
= SUMMARY: AddressSanitizer: heap-buffer-overflow /home/travis/build/neovim/neovim/src/nvim/mbyte.c:1637:7 in utf_head_off
stack traceback:
./test/helpers.lua:80: in function 'check_logs'
./test/functional/helpers.lua:639: in function <./test/functional/helpers.lua:638>
[----------] 9 tests from /home/travis/build/neovim/neovim/test/functional/terminal/buffer_spec.lua (2263.12 ms total)
Problem: It is not possible to use plugins in an "after" directory to tune
the behavior of a package.
Solution: First load plugins from non-after directories, then packages and
finally plugins in after directories.
Reset 'loadplugins' before executing --cmd arguments.
66459b7c98
vim-patch:7.4.2172
vim-patch:7.4.2169
vim-patch:7.4.2177
vim-patch:7.4.2178
vim-patch:7.4.2184
vim-patch:8.0.0050
vim-patch:8.0.0105
vim-patch:8.0.0400
vim-patch:8.0.0405
Closes#6034
The original patch makes all the modeline comments consistent, but these
have been removed in the neovim source. However there as a correction of
a comment included in the patch that we can use.
edf3f97ae2
Problem: printf() test fails on Windows. "-inf" is not used.
Solution: Check for Windows-specific values for "nan". Add sign to "inf"
when appropriate.
9992237a3e
Problem: When the same tag appears more than once, the order is
unpredictable. (Charles Campbell)
Solution: Besides using a dict for finding duplicates, use a grow array for
keeping the tags in sequence.
98e83b2956
Problem: Coverity gets confused by the flags passed to find_tags() and
warnts for an uninitialized variable.
Solution: Disallow using cscope and help tags at the same time.
fffbf308dd
Problem: Jumping to a tag that is a static item in the current file fails.
(Kazunobu Kuriyama)
Solution: Make sure the first byte of the tag key is not NUL. (Suggested by
James McCoy, closesvim/vim#1387)
a9d23c2087
Problem: Detecting duplicate tags uses a slow linear search.
Solution: Use a much faster hash table solution. (James McCoy, closesvim/vim#1046)
But don't add hi_keylen, it makes hash tables 50% bigger.
810f9c361c
Problem: 'formatprg' is a global option but the value may depend on the
type of buffer. (Sung Pae)
Solution: Make 'formatprg' global-local. (closesvim/vim#1380)
9be7c04e6c
Problem: Illegal memory access with ":1@". (Dominique Pelle)
Solution: Correct cursor column after setting the line number. Also avoid
calling end_visual_mode() when not in Visual mode.
4930a76a03
Problem: when calling an operator function when 'linebreak' is set, it is
internally reset before calling the operator function.
Solution: Restore 'linebreak' before calling op_function(). (Christian
Brabandt)
4a08b0dc4d
Problem: When using an Ex command for 'keywordprg' it is escaped as with a
shell command. (Romain Lafourcade)
Solution: Escape for an Ex command. (closesvim/vim#1175)
426f375422
Problem: Crash when closing a buffer while Visual mode is active.
(Dominique Pelle)
Solution: Adjust the position before computing the number of lines.
When closing the current buffer stop Visual mode.
c4a908e836
