If a second and third child exit while we are already in the handler, we
will only see a single additional SIGCHLD. Therefore the handler must
not stop after processing a single child but should check all children.
Fixes#8740
channel.c: WIP remove redundant method check and added FUNC_ATTR_NONNULL_ALL macro
channel.c channel_defs.h helpers.c: added Error field to RequestEvent, added no_op handler func
channel.c: use const char* instead of string and cleanup
channel.c; channel_defs.h; helpers.c: removed error from event again; send errors directly to the channel without using handlers and events
channel.c: fixed memory leak and lint errors
api/private/dispatch.c; api/vim.c; msgpack_rpc/channel.c msgpack_rpc/helpers.c added Error* field to msgpack_get_handler_for; further refactored channel.c
channel.c:323 changed order of evaluation in if statement
channel.c: removed superflous whitespace
dispatch.c: review comment
It seems as though in an AppImage there's an extra child process that
dies at some early point, before we have set up a SIGCHLD handler. So
when we later get a SIGCHLD from a child that we do care about,
waitpid(-1, ...) tells us about the extra child - and we don't notice
that the interesting child has exited.
Or something like that!
See also:
* https://patchwork.kernel.org/patch/9949491/ in which perf hit
something similar
* discussion at the AppImage repository:
https://github.com/AppImage/AppImageKit/issues/812#issuecomment-404662110.
Fix is to be explicit about which process we are waitpid()'ing for, so
we never need be distracted by children that we don't know about.
Fixes#8104
Problem: The :global command does not work recursively, which makes it
difficult to execute a command on a line where one pattern matches
and another does not match. (Miles Cranmer)
Solution: Allow for recursion if it is for only one line. (closesvim/vim#1760)
f84b122a99
Show a proper confirmation dialog when trying to unload a terminal buffer while
the confirm option is set or when :confirm is used.
Fixes https://github.com/neovim/neovim/issues/4651
* vim-patch:8.0.0474: the client-server feature is not tested
Problem: The client-server feature is not tested.
Solution: Add a test.
15bf76d40b
* vim-patch:8.0.0475: not enough testing for the client-server feature
Problem: Not enough testing for the client-server feature.
Solution: Add more tests. Add the remote_startserver() function. Fix that
a locally evaluated expression uses function-local variables.
7416f3e73a
* vim-patch:8.0.0492: a failing client-server request can make Vim hang
Problem: A failing client-server request can make Vim hang.
Solution: Add a timeout argument to functions that wait.
81b9d0bd5c
Include src/nvim/testdir/test_clientserver.vim changes from
patches 8.0.0477, 8.0.0479.
* vim-patch:8.0.0633: the client-server test is still a bit flaky
Problem: The client-server test is still a bit flaky.
Solution: Wait a bit for the GUI to start. Check that the version number
can be obtained.
60964f6874
Include src/nvim/testdir/test_clientserver.vim changes
from patches 8.0.0507, 8.0.0511.
* vim-patch:8.0.1251: invalid expressin passed to WaitFor()
Problem: Invalid expressin passed to WaitFor().
Solution: Check if the variable exists.
d97fbf171e
Now that uv.h is directly being included, pre-processing of
test/includes/pre/uv.h fails on Linux with
In file included from «SRCDIR»/neovim/test/includes/pre/uv.h:1:
In file included from /usr/include/uv.h:62:
/usr/include/uv/unix.h:72:11: fatal error: 'uv/pthread-barrier.h' file not found
# include "uv/pthread-barrier.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
This happens because we're missing -D_GNU_SOURCE (part of ${gen_cdefs}),
which makes the pthread_barrier_* functionality visible.
libuv users are only supposed to directly include uv.h. In v1.21.0, all
the uv-*.h headers were renamed to uv/*.h, which caused the unit tests
to fail with
[123/125] Generating post/uv-errno.h
FAILED: test/includes/post/uv-errno.h
cd «SRCDIR»/src/neovim/build/test/includes && /usr/bin/clang -std=c99 -E -P «SRCDIR»/src/neovim/test/includes/pre/uv-errno.h -I/usr/include -I/usr/include -o «SRCDIR»/neovim/build/test/includes/post/uv-errno.h
«SRCDIR»/src/neovim/test/includes/pre/uv-errno.h:1:10: error: 'uv-errno.h' file not found with <angled> include; use "quotes" instead
#include <uv-errno.h>
^~~~~~~~~~~~
"uv-errno.h"
The intention of the file is to extend libuv's error constants with more
values used by the unit tests. This can just as easily be achieved
without poking into pseudo-private header files.
Problem: Recorded key sequences may become invalid.
Solution: Add back KE_SNIFF removed in 7.4.1433. Use fixed numbers for the
key_extra enum.
8858498516
Longer summary lines for commits may be wrapped when downloading the
commit from GitHub. Unwrapping the lines ensures they can be compared
with the raw Vim commits.
The difference before and after this patch using:
./scripts/vim-patch.sh -r 8684
Before:
✘ Wrong commit message.
Expected:
vim-patch:8.0.1464: completing directory after :find does not add slash
Problem: Completing directory after :find does not add slash.
Solution: Adjust the flags for globpath(). (Genki Sky)
vim/vim@8a37b03
Actual:
vim-patch:8.0.1464: completing directory after :find does not
add slash
Problem: Completing directory after :find does not add slash.
Solution: Adjust the flags for globpath(). (Genki Sky)
After:
✔ Found expected commit message.
[ci skip]
Problem: MS-Windows: when 'clipboard' is "unnamed" yyp does not work in a
:global command.
Solution: When setting the clipboard was postponed, do not clear the
register.
3fcfa35f82
closes#8466closes#8664
Regression by 0d7daaad98.
- Fix length comparison.
- Fix loop(s) which iterated over all fields of array `pcc` even if it
was not filled up (try unicode 0x9f as statusline character).
Note about the tests:
- To input unicode with more than two hex digits you can use <C-v>U...:
a + U+fe20: a︠
a + U+fe20 + U+fe21: a︠︡
urxvt supports the xterm sequence for focus reporting in master / CVS
since 2016 [1].
This has not been released yet, but is expected to be in 9.23.
In 3d0ee17 a special case for rxvt was added, which requires a custom
urxvt extension, see #7578.
Since urxvt 9.23 is not released still, and extensions for handling this
manually appear to be in use, this sends both escape sequences for rxvt.
Fixes https://github.com/neovim/neovim/issues/8695.
1: 75264fa544 (diff-2c8f5590ce4fa7495edcf7572c89c77b)
It was not working for me in different terminals.
This patch makes it work in the same way like reverse.
Test:
:hi jediUsage cterm=standout | hi jediUsage
Problem: Still too many old style tests.
Solution: Convert a few more tests to new style. (Yegappan Lakshmanan,
closesvim/vim#2272)
430dc5d360
Skip Test_tag_file_encoding.
083_tag_search_with_file_encoding_spec.lua handles the same test case.
Problem: When typing CTRL-L in a window that's not the first one, another
redraw will happen later. (Christian Brabandt)
Solution: Reset must_redraw after calling screenclear().
9f5f7bf4d5
Use LuaJIT FFI to create char pointer.
Validate output with utf_ptr2char(), vim_iswordc() and vim_iswordp().
Use const for LuaJIT string-to-char conversion.
Problem: Characters below 256 that are not one byte are not always
recognized as word characters.
Solution: Make vim_iswordc() and vim_iswordp() work the same way. Add a test
for this. (Ozaki Kiichi)
4019cf90b8
Problem: Duplication of code for adding a list or dict return value.
Solution: Add rettv_dict_set() and rettv_list_set(). (Yegappan Lakshmanan)
45cf6e910c
closes#7383closes#7715
This implements the compromise described in #7383:
* low-priority CursorLine if foreground is not set
* high-priority ("same as Vim" priority) CursorLine if foreground is set
ref d1874ab282
ref 56eda2aa17
Problem: Cannot resize the window in a FileType autocommand. (Ingo Karkat)
Solution: Add the CMDWIN flag to :resize. (test by Ingo Karkat,
closesvim/vim#1804)
9c4fefffb6
Problem: Setting 'filetype' internally may cause the current buffer and
window to change unexpectedly.
Solution: Set curbuf_lock. (closesvim/vim#1734)
1814183b86
Problem: Freeing wrong memory when manipulating buffers in autocommands.
(James McCoy)
Solution: Also set the w_s pointer if w_buffer was NULL.
f1d13478e3
Problem: Problems with autocommands when opening help.
Solution: Avoid using invalid "varp" value. Allow using :wincmd if buffer
is locked. (closesvim/vim#1806, closesvim/vim#1804)
163095f088
Problem: writefile() continues after detecting an error.
Solution: Bail out as soon as an error is detected. (suggestions by Nikolai
Pavlov, closesvim/vim#1476)
8cf91286ca
Problem: Saving the redo buffer only works one time, resulting in the "."
command not working well for a function call inside another
function call. (Ingo Karkat)
Solution: Save the redo buffer at every user function call. (closesvim/vim#1619)
d4863aa99e
* vim-patch:8.0.0538: no test for falling back to default term value
Problem: No test for falling back to default term value.
Solution: Add a test.
85045a73db
* vim-patch:8.0.0539: startup test fails on Mac
Problem: Startup test fails on Mac.
Solution: Use another term name, "unknown" is known. Avoid a 2 second delay.
08f88b139d
* oldtest: nvim does not support ':set term'
The `external_blobs` target was not copying dependency files into
the correct subdirectories. This caused a bug where nvim-qt wouldn't
start because `qwindows.dll` was not located in the `platforms`
subdirectory.
closes https://github.com/equalsraf/neovim-qt/issues/422
Problem: When 'wrapscan' is off "gn" does not select the whole pattern when
it's the last one in the text. (KeyboardFire)
Solution: Check if the search fails. (Christian Brabandt, closesvim/vim#1683)
add8dce38d
Compare `$VIRTUAL_ENV` to `python_bin`.
This is necessary when `g:python_host_prog` is set to an absolute path,
and looking up `pyname` in `$PATH` yields another result.
vim-patch:8.0.1836: buffer-local window options may not be recent
Problem: Buffer-local window options may not be recent if the buffer is
still open in another window.
Solution: Copy the options from the window instead of the outdated window
options. (Bjorn Linse, closesvim/vim#2336)
25782a7ff4
Problem: The ":stag" command does not respect 'switchbuf'.
Solution: Check 'switchbuf' for tag commands that may open a new window.
(Ingo Karkat, closesvim/vim#1681) Define macros for the return values
of getfile().
8ad80dea08
Problem: After aborting an Ex command g< does not work. (Marcin
Szamotulski)
Solution: Postpone clearing scrollback messages to until the command line
has been entered. Also fix that the screen isn't redrawn if after
g< the command line is cancelled.
f2405ed232
vim-patch:8.0.0632: the quotestar test is still a bit flaky
Problem: The quotestar test is still a bit flaky.
Solution: Kill any existing server to make the retry work. Wait for the
register to be filled.
1c13c0fe3e
vim-patch:8.0.1536: quotestar test is flaky when using the GUI
Problem: Quotestar test is flaky when using the GUI.
Solution: Add check that the star register arrived at the server. Increase
timeouts.
791010e648
Problem: When setting the cterm background with ":hi Normal" the value of
'background' may be set wrongly.
Solution: Check that the color is less than 16. Don't set 'background' when
it was set explicitly. (Lemonboy, closesvim/vim#1710)
1615b36b91
Restore reset_option_was_set(), removed in 419da839e0
ref #8595
ref #8597
vim-patch:8.0.0469: compiler warnings on MS-Windows
Problem: Compiler warnings on MS-Windows.
Solution: Add type casts. (Christian Brabandt)
0c0d4eca4d
vim-patch:8.0.0581: moving folded text is sometimes not correct
Problem: Moving folded text is sometimes not correct.
Solution: Bail out when "move_end" is zero. (Matthew Malcomson)
94be619e30
vim-patch:8.0.0583: fold test hangs on MS-Windows
Problem: Fold test hangs on MS-Windows.
Solution: Avoid overflow in compare.
b11c826ddc
Problem: In Insert mode, CTRL-N at start of the buffer does not work
correctly. (zuloloxi)
Solution: Wrap around the start of the buffer. (Christian Brabandt)
24a9e348aa
Problem: Swap file exists briefly when opening the command window.
Solution: Set the noswapfile command modifier before splitting the window.
(James McCoy, closesvim/vim#1620)
3bab93998d
Problem: Illegal memory access with :z and large count.
Solution: Check for number overflow, using long instead of int. (Dominique
Pelle, closesvim/vim#1612)
fa0ad0bb0b
This ensures that special characters in the variables are not
interpreted as escapes/format characters in the printf string, as was
seen with upstream patch 8.0.0615.
$ ./scripts/vim-patch.sh -p 8.0.0615
Updating Vim sources: /$HOME/src/neovim/.vim-src
✔ Updated Vim sources.
✔ Found Vim revision 'bf15b8d78b22661db8b19d662b62bb9a061cdd37'.
Creating patch...
Pre-processing patch...
✔ Saved patch to '/$HOME/src/neovim/vim-8.0.0615.patch'.
Fetching 'origin/master'.
✔ From https://github.com/neovim/neovim
* branch master -> FETCH_HEAD
Creating new branch 'vim-8.0.0615' based on 'origin/master'.
✔ Switched to a new branch 'vim-8.0.0615'
Branch 'vim-8.0.0615' set up to track remote branch 'master' from 'origin'.
Creating empty commit with correct commit message.
./scripts/vim-patch.sh: line 40: printf: `w': invalid format character
✔ [vim-8.0.0615 db7fbb016] vim-patch:8.0.0615: using ./scripts/vim-patch.sh: line 44: printf: `w': invalid format character
✘ [vim-8.0.0615 db7fbb016] vim-patch:8.0.0615: using
[ci-skip]
Problem: The mode test may hang in Test_mode(). (Michael Soyka)
Solution: Set 'complete' to only search the current buffer (as suggested by
Michael)
ffea8c99d9
DWIM: avoid empty buffer 1 when stdin was empty. If other files were
specified at startup, we assume that stdin is only accidentally
not-a-TTY: user did not intend to send text from it.
ref #8560
ref #8561
If stdin is not a TTY we read it into buffer 1, as text. But if the
stdin pipe is empty, Nvim was most likely invoked for some other reason.
DWIM: select buffer 2 (if it exists). Example:
echo file1 | xargs nvim
closes#8560closes#8561
ref https://github.com/equalsraf/neovim-qt/issues/417
There's a mix of CXX and C related variables being set/referenced in our
CMake files. Since we only use C, use an explicit language list of "C"
instead of the implicit "C CXX" and replace all uses of CXX variables
with their C counterparts
The Debian hurd-i386 [build] failed (partly) due to -D_GNU_SOURCE not be
defined:
[215/286] /usr/bin/cc -DINCLUDE_GENERATED_DECLARATIONS -Iconfig -I../src -Isrc/nvim/auto -Iinclude -I/usr/include/luajit-2.1 -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -MD -MT src/nvim/CMakeFiles/nvim.dir/os/pty_process_unix.c.o -MF src/nvim/CMakeFiles/nvim.dir/os/pty_process_unix.c.o.d -o src/nvim/CMakeFiles/nvim.dir/os/pty_process_unix.c.o -c ../src/nvim/os/pty_process_unix.c
../src/nvim/os/pty_process_unix.c: In function 'pty_process_tty_name':
../src/nvim/os/pty_process_unix.c:121:10: warning: implicit declaration of function 'ptsname'; did you mean 'ttyname'? [-Wimplicit-function-declaration]
return ptsname(ptyproc->tty_fd);
Hurd is obviously not Linux, but it is using a GNU compiler and glibc so
it needs -D_GNU_SOURCE for the ptsname() definition to be visible.
[build]: https://buildd.debian.org/status/fetch.php?pkg=neovim&arch=hurd-i386&ver=0.3.0-2&stamp=1528981349&raw=0
Enabling CMake's USE_FOLDERS option and adding the FOLDER property to
targets allows some IDEs to list the targets in an organized
hierarchy of folders.
Before this change, -E/-Es without `-u NONE` reads stdin as Ex commands.
It should always read stdin as text (into buffer 1), like this:
echo foo | nvim -Es +'%p'
foo
echo foo | nvim -Es -u NORC +'%p'
foo
This changes Ex mode (Q, -e) to work like Vim's "improved Ex mode"
(gQ, -E). That brings some small behavior differences, but should not
impact most Ex scripts (unless, for example, they depend on mappings
being disabled--but that can be solved for -e by skipping user config).
Before this change:
* the screen test hangs.
After this change:
* Q acts like gQ.
* -e/-es differs from -E/-Es only in its treatment of stdin.
This moves towards potentially removing getexmodeline().
(HINT: That does NOT mean "removing Ex mode", it means removing the
Vi-compatible Ex mode, which differs from Vim's "improved Ex mode" only
in some minor details (e.g. mappings are disabled).)
ref #1089 :-)~
Problem: For some people the hint about quitting is not sufficient.
Solution: Put <Enter> separately. Also use ":qa!" to get out even when
there are changes.
28a8193e31
Problem: shellescape() always escapes a newline, which does not work with
some shells. (Harm te Hennepe)
Solution: Only escape a newline when the "special" argument is non-zero.
(Christian Brabandt, closesvim/vim#1590)
206155280d
Problem: When gF fails to edit the file the cursor still moves to the found
line number.
Solution: Check the return value of do_ecmd(). (Michael Hwang)
2a79ed293c
Problem: Test_edit causes older xfce4-terminal to close. (Dominique Pelle)
Solution: Reduce number of columns to 2000. Try to restore the window
position.
ba6ec18297
Problem: Buffer overflow when 'columns' is very big. (Nikolai Pavlov)
Solution: Correctly compute where to truncate. Fix translation.
(closesvim/vim#1600)
658a3a2caf
Fix PVS warnings:
fileio.c:7293 Medium V547 Expression is always true.
fileio.c:7351 Medium V547 Expression 'event == 100' is always false.
event_name2nr returns event_T, so PVS infers that nothing outside of
that range could possibly be returned.
According to POSIX[0], only octal escapes are supported by the printf
command. GNU coreutils' printf and some shells' builtin printf versions
which support hex escapes, but dash and non-GNU printf do not.
[0]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
Store text in ScreenLines as UTF-8, so it can be sent as-is to the UI
layer. `utfc_char2bytes(off,buf)` is removed, as `ScreenLines[off]` now
already contains this representation.
To recover the codepoints that the screen arrays previously contained, use
utfc_ptr2char (or utf_ptr2char to ignore composing chars).
NB: This commit does NOT change how screen.c processes incoming UTF-8 data
from buffers, cmdline, messages etc. Any algorithm that operates on UCS-4
(like arabic shaping, treatment of non-printable chars)
is left unchanged for now.
Problem: Crash when complete() is called after complete_add() in
'completefunc'. (Lifepillar)
Solution: Bail out if compl_pattern is NULL. (closesvim/vim#1668)
Also avoid using freed memory.
4475b62396
Environment variables are used to detect when the project is being built
from within Clion or Visual Studio, so that the build process can be
simplified by automatically building the bundled dependencies for them.
Problem: Using a function pointer instead of the actual function, which we
know.
Solution: Change mb_ functions to utf_ functions when already checked for
Unicode. (Dominique Pelle, closesvim/vim#1582)
ace95989ed
ref be68f218ff
[OLDTEST] Running test_options
Failed: F /tests/oldtests|test_options :: Nvim exited with non-zero code
-en travis_fold:start:-tests-oldtests-test-options
=================================================================
==26191==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x621000067900 at pc 0x0000004768bd bp 0x7ffe6bd02de0 sp 0x7ffe6bd02580
READ of size 4096 at 0x621000067900 thread T0
0 0x4768bc in __interceptor_getpwnam /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1726:3
1 0x12847c5 in os_get_user_directory /home/travis/build/neovim/neovim/build/../src/nvim/os/users.c:82:8
2 0x125a3e3 in expand_env_esc /home/travis/build/neovim/neovim/build/../src/nvim/os/env.c:380:25
3 0x1257fdb in expand_env_save_opt /home/travis/build/neovim/neovim/build/../src/nvim/os/env.c:255:3
4 0x1291b77 in gen_expand_wildcards /home/travis/build/neovim/neovim/build/../src/nvim/path.c:1195:13
5 0x129e2e7 in expand_wildcards /home/travis/build/neovim/neovim/build/../src/nvim/path.c:2018:12
6 0x129e193 in expand_wildcards_eval /home/travis/build/neovim/neovim/build/../src/nvim/path.c:1986:11
7 0xc2ddc3 in ExpandFromContext /home/travis/build/neovim/neovim/build/../src/nvim/ex_getln.c:4685:11
8 0xc29412 in ExpandOne /home/travis/build/neovim/neovim/build/../src/nvim/ex_getln.c:3775:9
9 0x931364 in f_expand /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:8257:32
10 0x811954 in call_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6373:11
11 0x8256b8 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6119:11
12 0x8ad6a1 in eval7 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:4217:15
13 0x8a9c6b in eval6 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3914:7
14 0x8a797f in eval5 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3765:7
15 0x8a319f in eval4 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3502:7
16 0x8a263c in eval3 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3420:7
17 0x8a1adc in eval2 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3351:7
18 0x809b21 in eval1 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3278:7
19 0x824f24 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6092:9
20 0x81e674 in ex_call /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:2726:9
21 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
22 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
23 0x845232 in call_user_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:21396:3
24 0x81127b in call_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6358:11
25 0x8256b8 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6119:11
26 0x81e674 in ex_call /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:2726:9
27 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
28 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
29 0x8645f1 in ex_execute /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:19541:7
30 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
31 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
32 0x845232 in call_user_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:21396:3
33 0x81127b in call_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6358:11
34 0x8256b8 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6119:11
35 0x81e674 in ex_call /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:2726:9
36 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
37 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
38 0xb19f2d in do_source /home/travis/build/neovim/neovim/build/../src/nvim/ex_cmds2.c:2973:3
39 0xb16580 in cmd_source /home/travis/build/neovim/neovim/build/../src/nvim/ex_cmds2.c:2718:14
40 0xb16677 in ex_source /home/travis/build/neovim/neovim/build/../src/nvim/ex_cmds2.c:2699:3
41 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
42 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
43 0xb362c5 in do_cmdline_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:278:10
44 0xe8e3a3 in exe_commands /home/travis/build/neovim/neovim/build/../src/nvim/main.c:1705:5
45 0xe7bbba in main /home/travis/build/neovim/neovim/build/../src/nvim/main.c:518:5
46 0x2b0e17bd1f44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
47 0x44dcfb in _start (/home/travis/build/neovim/neovim/build/bin/nvim+0x44dcfb)
0x621000067900 is located 0 bytes to the right of 4096-byte region [0x621000066900,0x621000067900)
allocated by thread T0 here:
0 0x4eeed3 in malloc /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67:3
1 0xf87981 in try_malloc /home/travis/build/neovim/neovim/build/../src/nvim/memory.c:87:15
2 0xf87ba9 in xmalloc /home/travis/build/neovim/neovim/build/../src/nvim/memory.c:121:15
3 0x1257f6f in expand_env_save_opt /home/travis/build/neovim/neovim/build/../src/nvim/os/env.c:254:15
4 0x1291b77 in gen_expand_wildcards /home/travis/build/neovim/neovim/build/../src/nvim/path.c:1195:13
5 0x129e2e7 in expand_wildcards /home/travis/build/neovim/neovim/build/../src/nvim/path.c:2018:12
6 0x129e193 in expand_wildcards_eval /home/travis/build/neovim/neovim/build/../src/nvim/path.c:1986:11
7 0xc2ddc3 in ExpandFromContext /home/travis/build/neovim/neovim/build/../src/nvim/ex_getln.c:4685:11
8 0xc29412 in ExpandOne /home/travis/build/neovim/neovim/build/../src/nvim/ex_getln.c:3775:9
9 0x931364 in f_expand /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:8257:32
10 0x811954 in call_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6373:11
11 0x8256b8 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6119:11
12 0x8ad6a1 in eval7 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:4217:15
13 0x8a9c6b in eval6 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3914:7
14 0x8a797f in eval5 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3765:7
15 0x8a319f in eval4 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3502:7
16 0x8a263c in eval3 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3420:7
17 0x8a1adc in eval2 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3351:7
18 0x809b21 in eval1 /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:3278:7
19 0x824f24 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6092:9
20 0x81e674 in ex_call /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:2726:9
21 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
22 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
23 0x845232 in call_user_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:21396:3
24 0x81127b in call_func /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6358:11
25 0x8256b8 in get_func_tv /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:6119:11
26 0x81e674 in ex_call /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:2726:9
27 0xb4db73 in do_one_cmd /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:2238:5
28 0xb30119 in do_cmdline /home/travis/build/neovim/neovim/build/../src/nvim/ex_docmd.c:602:20
29 0x8645f1 in ex_execute /home/travis/build/neovim/neovim/build/../src/nvim/eval.c:19541:7
SUMMARY: AddressSanitizer: heap-buffer-overflow /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:1726:3 in __interceptor_getpwnam
Shadow bytes around the buggy address:
0x0c4280004ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4280004ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4280004ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4280004f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4280004f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c4280004f20:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280004f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280004f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280004f50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280004f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4280004f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==26191==ABORTING
Failed: E /tests/oldtests|logs :: Runtime errors detected.
Job exited with code 1
Screen (23 lines)
Problem: Using uninitialized memory when 'isfname' is empty.
Solution: Don't call getpwnam() without an argument. (Dominique Pelle,
closesvim/vim#1464)
187a4f2814
Problem: May get ml_get error when :pydo deletes lines or switches to
another buffer. (Nikolai Pavlov, issue vim/vim#1421)
Solution: Check the buffer and line every time.
a58883b4ea
(We only include the tests, the Vim code changes are N/A for Nvim.)
Problem: When using an assert function one can either specify a message or
get a message about what failed, not both.
Solution: Concatenate the error with the message.
c7b831ca15
Problem: When calling setpos() with a buffer argument it often is ignored.
(Matthew Malcomson)
Solution: Make the buffer argument work for all marks local to a buffer.
(neovim vim/vim#5713) Add more tests.
f13e00b2cf
- We need the gettext tools (msgmerge.exe) because these aren't built
when we build from source (not trivial).
- We can use the pre-built libiconv-2.dll for DYNAMIC_ICONV_DLL.
If check_c_source_compiles() succeeded (HAVE_WORKING_LIBINTL is set)
then the result of find_xxx() doesn't matter. This happens on systems
(linux+glibc) where libintl is available passively.
This allows `find_package(LibIntl REQUIRED)` to work and will still
correctly fail (REQUIRED) on systems lacking libintl.
"Always use `find_package` with `REQUIRED`."
- We make an exception for LuaJit (not REQUIRED): the `nvim-test` target
is included only if we can find LuaJit.
This is partially a cargo-cult (reference below), but it uncovered at
least one problem: `find_package(LibIntl REQUIRED)` fails on my vanilla
ubuntu 16.04 system.
ref: https://schneide.blog/2017/11/06/4-tips-for-better-cmake/
> optional dependencies is nice, but skipping on REQUIRED is not the way
> you want to do it. In the worst case, some of your features will just
> not work if those packages are not found, with no explanation
> whatsoever. Instead, use explicit feature-toggles (e.g. using option())
> that either skip the find_package call or use it with REQUIRED, so the
> user will know that another lib is needed for this feature.
Problem: 'colorcolumn' has a higher priority than 'hlsearch', it should be
the other way around. (Nazri Ramliy)
Solution: Change the priorities. (LemonBoy, closesvim/vim#1794)
774e5a9673
Problem: 'smartindent' is used even when 'indentexpr' is set.
Solution: Ignore 'smartindent' when 'indentexpr' is set. (Hirohito Higashi)
69a76feda9
---
This also fixes "delfunction!" which was not merged fully in a185ab70fd (vim-patch:8.0.0655)
Problem: Line in test commented out.
Solution: Uncomment the lines for character classes that were failing before
8.0.0519. (Dominique Pelle, closesvim/vim#1599)
13489b9c41
Fixes 2 failing tests in startup_spec.lua.
The Windows-only `--literal` option complicates support of "stdin-as-text
+ file-args" (#7679). Could work around it, but it's not worth
the trouble:
- users have a reasonable (and englightening) alternative: nvim +"n *"
- "always literal" is more consistent/predictable
- avoids platform-specific special-case
Unrelated changes:
- Replace fileno(stdxx) with STDXX_FILENO for consistency (not motivated
by any observed technical reason).
silent-mode (-es/-Es) has been broken for years. The workaround up to
now was to include --headless. But --headless is not equivalent because
it prints all messages, not the limited subset defined by silent-mode.
silent-mode (AKA batch-mode, -es/-Es) by definition should not behave
like a UI.
There are still some places that check `full_screen` to decide behavior,
e.g. msg_start(). Future: maybe eliminate `full_screen`, check
`ui_active()` instead?
Special-case for -E/-Es (as opposed to -e/-es).
-es/-Es is the only mode that really allows N/Vim to work as a batch
script engine. Adding a new flag (say `-x`) would involve a lot of
churn: -es/-Es is implemented by checking `exmode_active` in numerous
places.
This commit does not change -es because some scripts use it. But scripts
are unlikely to use -Es because it is not functionally different from
-es.
Also, both -es and -Es were broken in Nvim for years and no one
mentioned it...
Treat stdin as text by default (so the "-" file is not needed):
echo foo | nvim
It works with file args (implemented in next commit), too:
echo foo | nvim file1.txt file2.txt
Why? Because:
- Execution of input is (1) almost always unintentional/confusing,
and (2) potentially destructive.
- Avoids the need for time-delayed warning. #7659
- The _common_ case is to open text in a buffer, not send commands.
Note:
- Not for Ex-mode (-es) because it is used by scripts. But maybe `-Es`?
- Not for --headless, because stdio may be a protocol stream and may be
used for any purpose by stdioopen().
To treat stdin as Normal-mode commands, use `-s -` instead:
echo ifoo | nvim -s -
Other alternatives:
- Replay a register. E.g. the following mostly works, except @q aborts
on any "beep" (e.g. if the cursor can't move).
nvim -c '%d q|norm @q' -
- Future: Let `:%source` work with unsaved buffer contents?
closes#2087closes#7659
This code was essentially dead because this condition:
(!parmp->err_isatty && (!parmp->output_isatty || !parmp->input_isatty))
is almost never true.
ref #7659
vim-patch:8.0.0399: crash when using balloon_show() when not supported
Problem: Crash when using balloon_show() when not supported. (Hirohito
Higashi)
Solution: Check for balloonEval not to be NULL. (Ken Takata)
caf6434ac9
vim-patch:8.0.0401: test fails with missing balloon feature
Problem: Test fails with missing balloon feature.
Solution: Add check for balloon feature.
a0107bdf87
vim-patch:8.0.0414: balloon eval is not tested
Problem: ":set scroll&" often gives an error.
Solution: Don't use a fixed default value, use half the window height. Add a
test. (Ozaki Kiichi, closesvim/vim#2104)
af2d20c628
vim-patch:8.0.0349: redrawing errors with GTK 3
vim-patch:8.0.0363: Travis is too slow to keep up with patches
vim-patch:8.0.0366: build fails with tiny features
vim-patch:8.0.0373: build fails without +folding
vim-patch:8.0.0397: can't build with +viminfo but without +eval
vim-patch:8.0.0410: newer gettext/iconv library has extra dll file-
vim-patch:8.0.0418: ASAN logs are disabled
vim-patch:8.0.0445: getpgid is not supported on all systems-
vim-patch:8.0.0449
vim-patch:8.0.0462: failure of an MS-Windows test may go unnoticed
vim-patch:8.0.0494: build failure with older compiler on MS-Windows
vim-patch:8.0.0501: on MS-Windows ":!start" does not work as expected
vim-patch:8.0.0508: Coveralls no longer shows per-file coverage
vim-patch:8.0.0509: no link to codecov.io results
vim-patch:8.0.0510: typo in link to codecov.io results
vim-patch:8.0.0512: check for available characters takes too long
vim-patch:8.0.0521: GtkForm handling is outdated
vim-patch:8.0.0527: leftover file from RISC OS
vim-patch:8.0.0534: defaults.vim does not work well with tiny features
vim-patch:8.0.0557: GTK: using static gravities is not useful
vim-patch:8.0.0566: setting nocompatible for the tiny version moves the cursor
vim-patch:8.0.0570: can't run make with several jobs
vim-patch:8.0.0573: running parallel make after distclean fails
vim-patch:8.0.0576: can't build when configure choses "install-sh"
vim-patch:8.0.0578: :simalt on MS-Windows does not work properly
vim-patch:8.0.0589: :simalt still does not work
vim-patch:8.0.0594: build failure when windows feature is missing
vim-patch:8.0.0619: GUI gets stuck if timer uses feedkeys()
vim-patch:8.0.0624: warning for unused variable in tiny build
vim-patch:8.0.0638: cannot build with new MSVC version
vim-patch:8.0.0651: build failure without the auto command feature
vim-patch:8.0.0695: missing dependencies breaks parallel make
vim-patch:8.0.0711: cannot build without the wildmenu feature
vim-patch:8.0.0756: cannot build libvterm with MSVC
vim-patch:8.0.0757: libvterm MSVC Makefile not included in the distribution
vim-patch:8.0.0765: build fails with tiny features
vim-patch:8.0.0767: build failure with Athena and Motif
vim-patch:8.0.0780: build failure on Travis
vim-patch:8.0.0786: build failures on Travis
vim-patch:8.0.0796: no coverage on Travis with clang
vim-patch:8.0.0814: file in Filelist does not exist
vim-patch:8.0.0961: the script to build the installer does not include winpty
vim-patch:8.0.0989: ActiveTcl dll name has changed in 8.6.6
vim-patch:8.0.1032: "make tags" doesn't work well on MS-Windows-
vim-patch:8.0.1050: terminal window feature not included by default
vim-patch:8.0.1056: cannot build with +diff but without +multi_byte-
vim-patch:8.0.1084: GTK build has compiler warnings
vim-patch:8.0.1086: can't build with GTK 3
vim-patch:8.0.1098: build failure if libvterm installed
vim-patch:8.0.1099: warnings for GDK calls
vim-patch:8.0.1122: vimtutor.bat doesn't work well with vim.bat
vim-patch:8.0.1124: use of MZSCHEME_VER is unclear
vim-patch:8.0.1147: fail to build with tiny features
vim-patch:8.0.1156: trouble from removing one -W argument from Perl CFLAGS
vim-patch:8.0.1178: using old compiler on MS-Windows
vim-patch:8.0.1183: MS-Windows build instructions are outdated
vim-patch:8.0.1185: Ruby library includes minor version number
vim-patch:8.0.1187: building with lua fails for OSX on Travis
vim-patch:8.0.1196: crash when t_RF is not set
vim-patch:8.0.1212: MS-Windows: tear-off menu does not work on 64 bit
vim-patch:8.0.1233: typo in dos installer
vim-patch:8.0.1235: cannot disable the terminal feature in a huge build
vim-patch:8.0.1252: incomplete translations makefile for MinGW/Cygwin
vim-patch:8.0.1268: PC install instructions are incomplete
vim-patch:8.0.1288: GUI: cannot drag the statusline of a terminal window
vim-patch:8.0.1294: GUI: get stuck when splitting a terminal window
vim-patch:8.0.1301: generated license file for NSIS has a modeline
vim-patch:8.0.1313: missing dependencies cause parallel make to fail
vim-patch:8.0.1314: build fails on Mac
vim-patch:8.0.1351: warning for unused variables building with MinGW
vim-patch:8.0.1373: no error when settting 'renderoptions' before starting GUI
vim-patch:8.0.1379: configure check for selinux does not check for header file
vim-patch:8.0.1385: Python 3.5 is getting old
vim-patch:8.0.1390: DirectX scrolling can be slow, vertical positioning is off
vim-patch:8.0.1392: build fails with --with-features=huge --disable-channel
vim-patch:8.0.1399: warnings and errors when building tiny version
vim-patch:8.0.1401: cannot build with GTK but without XIM
vim-patch:8.0.1407: GUI: CursorHold may trigger before 'updatetime'
vim-patch:8.0.1431: MS-Windows: vimtutor fails if %TMP% has special chars
vim-patch:8.0.1444: missing -D_FILE_OFFSET_BITS=64 may cause problems
vim-patch:8.0.1450: GUI: endless loop when stopping cursor blinking
vim-patch:8.0.1466: older GTK versions don't have gtk_entry_get_text_length()
vim-patch:8.0.1471: on MS-Windows CursorIM highlighting no longer works
vim-patch:8.0.1473: MS-Windows: D&D fails between 32 and 64 bit apps
vim-patch:8.0.1474: Visual C 2017 has multiple MSVCVER numbers
vim-patch:8.0.1530: dump test fails when using a shadow directory-
vim-patch:8.0.1548: screen dump test script not included in distribution-
vim-patch:8.0.1555: build error for some combination of features
vim-patch:8.0.1559: build failure without GUI
vim-patch:8.0.1560: build failure without GUI on MS-Windows
vim-patch:8.0.1800: X11: getting color is slow-
vim-patch:8.0.1808: can't build without TGETENT-
vim-patch:8.0.1822: make uninstall does not remove colors/tools-
vim-patch:8.0.1826: configure uses old compiler flag-
vim-patch:8.0.1828: get no clue why :gui does not fork-
vim-patch:8.0.1833: X11: ":echo 3.14" gives E806-
vim-patch:8.0.1834: GUI: find/replace dialog does not handle some chars-
vim-patch:8.0.1847: some build options don't have an example-
Problem: Character classes are not well tested. They can differ between
platforms.
Solution: Add tests. In the documentation make clear which classes depend
on what library function. Only use :cntrl: and :graph: for ASCII.
(Kazunobu Kuriyama, Dominique Pelle, closesvim/vim#1560)
Update the documentation.
0c078fc7db
Problem: MS-Windows users are confused about default mappings.
Solution: Don't map keys in the console where they don't work. Add a choice
in the installer to use MS-Windows key bindings or not. (Christian
Brabandt, Ken Takata, closesvim/vim#2093)
c3fdf7f80b
Problem: When using the tiny version trying to load the matchit plugin
gives an error. On MS-Windows some default mappings fail.
Solution: Add a check if the command used is available. (Christian Brabandt)
8cc2a9c062
Problem: ml_get errors in silent Ex mode. (Dominique Pelle)
Solution: Clear valid flags when setting the cursor. Set the topline when
not in full screen mode.
d5d37537d1
Problem: Menuage for skipping client-server tests is unclear.
Solution: Be more specific about what's missing (Hirohito Higashi, Kazunobu
Kuriyama)
a683ec44c3
Problem: Failed window split for :stag not handled. (Coverity CID 99204)
Solution: If the split fails skip to the end. (bstaletic, closesvim/vim#1577)
ba6ad17378
mkfifo (msysgit) does not work outside of msys2 environment.
gzip tests fail on Windows.
mklink requires admin privs for file symbolic links so mklink fails.
`cat` is distributed with neovim, so when can use it everywhere, as
opposed to `sort`.
The diffget test fails for unknown reasons on appveyor, mark it pending
for now.
Problem: The quotestar test uses a timer instead of a timeout, thus it
cannot be rerun like a flaky test.
Solution: Remove the timer and add a timeout. (Kazunobu Kuriyama)
f5610da7a8
vim-patch:8.0.0312: failure when a channel receives a split json message
vim-patch:8.0.0313: not enough testing for GUI functionality
vim-patch:8.0.0317: no test for setting 'guifont'
vim-patch:8.0.0318: small mistake in 7x13 font name
vim-patch:8.0.0329: xfontset and guifontwide are not tested
vim-patch:8.0.0332: GUI test fails on some systems
vim-patch:8.0.0348: using shadow dir on Mac lack +clipboard
vim-patch:8.0.0356: leaking memory when setting 'ttytype'
vim-patch:8.0.0362: tests fail on MS-Windows
vim-patch:8.0.0371: leaking memory when setting v:completed_item
vim-patch:8.0.0375: the "+ register is not tested
vim-patch:8.0.0382: warning in tiny build for unused variable
vim-patch:8.0.0383: misplaced vim/vim#ifdef
vim-patch:8.0.0384: timer test failed for no apparent reason
vim-patch:8.0.0403: GUI tests may fail
vim-patch:8.0.0409: set_progpath is defined but not always used
vim-patch:8.0.0415: balloon test fails on MS-Windows
vim-patch:8.0.0416: setting v:progpath is not quite right
vim-patch:8.0.0419: test for v:progpath fails on MS-Windows
vim-patch:8.0.0438:
vim-patch:8.0.0441: dead code in vim/vim#ifdef
vim-patch:8.0.0447: getting font name does not work on X11
vim-patch:8.0.0450: v:progpath is not reliably set
vim-patch:8.0.0456: typo in MinGW test makefile
vim-patch:8.0.0460: can't build on HPUX
vim-patch:8.0.0463: side effects from resetting 'compatible' in defaults.vim
vim-patch:8.0.0464: can't find executable name on Solaris and FreeBSD
vim-patch 8.0.0809: MS-Windows: tests hang
vim-patch 8.0.0810: MS-Windows: tests still hang
vim-patch 8.0.0811: MS-Windows: test_expand_dllpath fails
vim-patch:8.0.0881: win32.mak no longer included in Windows SDK
vim-patch:8.0.0925: MS-Windows GUI: channel I/O not handled right away
vim-patch:8.0.1121: can uncheck executables in MS-Windows installer
vim-patch:8.0.1141: MS-Windows build dependencies are incomplete
vim-patch:8.0.1150: MS-Windows GUI: dialog font size is incorrect
vim-patch:8.0.1180: MS-Windows testclean target deletes the color script
vim-patch:8.0.1181: tests using Vim command fail on MS-Windows
vim-patch:8.0.1191: MS-Windows: missing 32 and 64 bit files in installer
vim-patch:8.0.1197: MS-Windows build instructions are not up to date
vim-patch:8.0.1234: MS-Windows: composing chars are not shown properly
vim-patch:8.0.1472: MS-Windows: nsis installer is a bit slow
Problem: Setting ttytype to xxx does not always fail as expected. (Marvin
Schmidt)
Solution: Catch both possible errors. (closesvim/vim#1601)
f803a76978
Problem: Double free when compiled with EXITFREE and setting 'ttytype'.
Solution: Avoid setting P_ALLOCED on 'ttytype'. (Dominique Pelle,
closesvim/vim#1461)
673911457d
likely fixes#7768#7913
If multiple internal stream callbacks were recieved before vimL
callbacks got called, only invoke one vimL callback with all data.
win_split() does EMSG for all failure cases, so we don't need to log it.
Easiest thing to do here is ignore the return value (otherwise we need
to do some cleanup and might require some refactoring. jumpto_tag() can
deal with a failed split, so it's no big deal.
Looking at the implementation of u_save suggests that its failure is
a normal and expected situation (e.g. if undo isn't allowed for some
reason, it will fail). Also (most of) the other calls to u_save() in
do_put() return early.
Problem: No autocmd triggered in Insert mode with visible popup menu.
Solution: Add TextChangedP. (Prabir Shrestha, Christian Brabandt,
closesvim/vim#2372, closesvim/vim#1691)
Fix that the TextChanged autocommands are not always triggered
when sourcing a script.
5a09343719
fixes#6974
Before this change, the partial could be freed before the last due
callback got invoked, which caused a use-after-free when the due
callback called the partial.
OpenBSD's man returns all candidates when searching with -w instead of
the first one it finds. So this patch takes the first one if multiple
entries are found.
closes#8372closes#8341
This condition is not perfectly reliable:
(did_emsg && force_abort && !current_exception)
The more proper way to check for abort-causing non-exception errors is
to set up `msg_list` using the "pattern" given by do_cmdline().
- Return VimL errors instead of generic errors for:
- nvim_call_function
- nvim_call_dict_function
- Fix tests which were silently broken before this change.
This violates #6150 where we agreed not to translate API errors. But
that can be fixed later.
The `internal` param is difficult to explain, and will rarely be
anything but `true`. To avoid it, use a hack: check if the resolved
dict value starts with "function(".
Make `:verbose set ...` show when an option was last modified by an
API client or Lua script/chunk. In the case of an API client, the
channel ID is displayed.
After this change we never release blocks from memory (in practice it
never happened because the memory limits are never reached). Let the OS
take care of that.
---
On today's systems the 'maxmem' and 'maxmemtot' values are huge (4+ GB)
so the limits are never reached in practice, but Vim wastes a lot of
time checking if the limit was reached.
If the limit is reached Vim starts saving pieces of the swap file that were in
memory to the disk. Said in a different way: Vim implements its own
memory-paging mechanism. This is unnecessary and inefficient since the
operating system already has virtual memory and will swap to the disk if
programs start using too much memory.
This change does...
1. Reduce the number of config options and need for documentation.
2. Make the code more efficient as we don't have to keep track of memory
usage nor check if the memory limits were reached to start swapping
to disk every time we need memory for buffers.
3. Simplify the code. Once memfile.c is simple enough it could be
replaced by actual operating system memory mapping (mmap,
MemoryViewOfFile...). This change does not prevent Vim to recover
changes from swap files since the swapping code is never triggered
with the huge limits set by default.
Remove "" from sys.path (typically the first entry), which could cause
e.g. "logging" to be added from the current directory.
This gets done already for loading the host in
runtime/autoload/provider/pythonx.vim.
Some terminals don't report which buttons are involved in some mouse
events. For example, the urxvt protocol
(http://www.huge-man-linux.net/man7/urxvt.html section "Mouse
reporting") does not report which button has been released.
In this case libtermkey reports button 0
(http://www.leonerd.org.uk/code/libtermkey/doc/termkey_interpret_mouse.3.html)
Up to now, forward_mouse_event did not handle button==0.
On press events there is not much we can do, and we keep the
current behavior which is dropping the event. But on drag-and-release
events we can compensate by remembering the last button pressed.
fixes#3182 for urxvt
fixes#5400
While warning is technically true (cannot enter this case with `state->c`
greater then NFA_Z…9) it makes condition less readable and relies on knownledge
of enum internal structure.
ref #6725
fsync() is very slow on some systems. And since the parent commit, Nvim
is smarter about flushing files at certain times (e.g. CursorHold),
regardless of whether 'fsync' is enabled. So it's less risky to disable
'fsync'.
Profiling showed slow (2-4s) :write and :quit caused by fsync():
:quit
shada_write_file(NULL, false);
:write + fsync
0 0x00007f72da567b2d in fsync () at ../sysdeps/unix/syscall-template.S:84
1 0x0000000000638970 in uv__fs_fsync (req=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:150
2 uv__fs_work (w=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:953
3 0x0000000000639a70 in uv_fs_fsync (loop=<optimized out>, req=<optimized out>, file=41, cb=0x7f72da567b2d <fsync+45>)
at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:1094
4 0x0000000000573694 in os_fsync (fd=41) at ../src/nvim/os/fs.c:631
5 0x00000000004ec9dc in buf_write (buf=<optimized out>, fname=<optimized out>, sfname=<optimized out>, start=1, end=1997, eap=0x7fffc864c570,
append=<optimized out>, forceit=<optimized out>, reset_changed=<optimized out>, filtering=<optimized out>) at ../src/nvim/fileio.c:3387
6 0x00000000004b44ff in do_write (eap=0x7fffc864c570) at ../src/nvim/ex_cmds.c:1745
...
:write + nofsync
0 0x00007f72da567b2d in fsync () at ../sysdeps/unix/syscall-template.S:84
1 0x0000000000638970 in uv__fs_fsync (req=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:150
2 uv__fs_work (w=<optimized out>) at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:953
3 0x0000000000639a70 in uv_fs_fsync (loop=<optimized out>, req=<optimized out>, file=36, cb=0x7f72da567b2d <fsync+45>)
at /home/vagrant/neovim/.deps/build/src/libuv/src/unix/fs.c:1094
4 0x0000000000573694 in os_fsync (fd=36) at ../src/nvim/os/fs.c:631
5 0x0000000000528f5a in mf_sync (mfp=0x7f72d8968d00, flags=5) at ../src/nvim/memfile.c:466
6 0x000000000052d569 in ml_preserve (buf=0x7f72d890f000, message=0) at ../src/nvim/memline.c:1659
7 0x00000000004ebadf in buf_write (buf=<optimized out>, fname=<optimized out>, sfname=<optimized out>, start=1, end=1997, eap=0x7fffc864c570,
append=<optimized out>, forceit=<optimized out>, reset_changed=<optimized out>, filtering=<optimized out>) at ../src/nvim/fileio.c:3071
8 0x00000000004b44ff in do_write (eap=0x7fffc864c570) at ../src/nvim/ex_cmds.c:1745
...
Vim has the 'swapsync' option which we removed in 62d137ce09.
Instead let 'fsync' control swapfile-fsync.
These cases ALWAYS force fsync (ignoring 'fsync' option):
- Idle (CursorHold).
- Exit caused by deadly signal.
- SIGPWR signal.
- Explicit :preserve command.
Avoid a hot loop in retry(), there's no need to retry more than 50/s.
Also use luv.sleep() to implement sleep() instead of spinning the
event-loop, so events are not silently discarded.
plog-converter behaviour is not the best one when creating fullhtml report and
directory already exists: it puts report inside an existing directory. Not sure
what exactly it does if inside exists as well, but if I am not mistaking report
will not be created.
Since `c` there is a result of evaluating `TO_SPECIAL` macros it may be only one
of the following three things:
1. K_SPECIAL
2. K_ZERO (note: not KS_ZERO)
3. negative integer resulting from evaluating TERMCAP2KEY macro.
All variants here are negative and thus fail next !IS_SPECIAL(c) check (negative
is special). If `c` was really NUL it would fall into the `!IS_SPECIAL(c)` block
and use whatever character is third in `<80>{a}{b}` combo. For `<Nul>` it is
X (`<80><ff>X`).
Some calculation show that with the current setup there will not be enough bytes
occupied for that, barring the case of malicious translation. Still should be
possible to have array overrun with specially crafted translation.
1. Don't check elapsed time in children_kill_cb(), it's already implied
by the start-time of the timer itself.
2. Restart timer from children_kill_cb() for PTY jobs, to send SIGKILL
after SIGTERM. There is an edge case where SIGKILL might follow
SIGTERM too quickly, if jobstop() is called near the 2-second timer
window. But this edge case is not worth code complication.
Before f31c26f1af the timer was used to try SIGTERM *and* SIGKILL, so
a repeating timer was needed. After f31c26f1af process_stop() sends
SIGTERM immediately, and the timer only sends SIGKILL.
So we don't need a repeating timer.
- Simplifies the logic: don't need to call uv_timer_stop() explicitly.
- Avoids a problem: if process_stop() is called more than once in the
2-second window, the first on_process_exit() would call
uv_timer_stop() which stops the timer for all stopped processes.
children_kill_cb() is racey. One obvious problem is that
process_close_handles() is *queued* by on_process_exit(), so when
children_kill_cb() is invoked, the dead process might still be in the
`loop->children` list. If the OS already reclaimed the dead PID, Nvim
may try to SIGKILL it.
Avoid that by checking `proc->status`.
Vim doesn't have this problem because it doesn't attempt to kill
processes that ignored SIGTERM after a timeout.
closes#8269
I failed to deduce why analyzer thinks E882 may not be triggered, though
conditions for triggering it are strange: it would trigger E882 only in the
single case “function returned non-number”. Cases “function thrown exception”,
or “built-in sorter encountered error” will neither yield E882 nor stop
sort()/uniq().
Note though that searching test code revealed that neither E702 nor E882 are not
tested anywhere.
Fixes#6890 by reading from the Windows console input buffer after
stdin has been closed.
Vim defines HAVE_DUP for Windows and does the close-dup dance[1]:
close(0);
dup(2);
which always fails, then falls back to reading from the Windows console
input buffer[2].
[1] e7499ddc33/src/fileio.c (L2397-L2398)
[2] e7499ddc33/src/os_win32.c (L1703-L1714)
* Reading from stdin on Windows is fixed in the same way as it was in
#8267.
* The file_read function was returning without filling the
destination buffer when it was called with a non-blocking file
descriptor.
It's only appropriate to set CMAKE_MAKE_PROGRAM to gmake when we're
using the "Unix Makefiles" generator. On QB, the nodes have Ninja
available and will use it, which means CMAKE_GENERATOR is set to
"Ninja". Setting CMAKE_MAKE_PROGRAM was forcing the build to use gmake
instead of ninja, which was causing the build failure.
This fixes an issue with compiles failing in release mode due to shape
having the possibility of being used uninitialized (since the default
case was missing).
Any user can create a directory on root.
Creating a directory on root allows any user to write files within that directory.
Test_recover_root_dir() passes when run locally as a regular user (not admin).
Unset $SHELL so that child nvim use cmd.exe as default shell.
Unset $TERM so that child nvim don't segfault with negative exit code.
sh/bash use TERM=cygwin by default if it is unset.
mintty sets TERM to xterm.
It is hard to say whether it actually is uninitialized, need to go deeper into
regex code. Probably analyzer did not go that far as regmatch for sure would not
be initialized up until calling NFA/DFA engine functions, which is to be done by
pointer.
It appears that transchar() was working under assumption that
`transchar_nonprint()` may be used for multibyte characters while its
documentation stated exact opposite. It was not actually untrue though, except
that longer buffer would be needed then the one stated in documentation. But it
is false now with assert().
The implementation of vim_fgets() differs between Neovim and Vim.
Vim says that it only returns `true` for EOF. But it always returns `true` when
fgets() returns NULL. This happens for EOF _or_ errors.
That probably misguided the author of Neovim's vim_fgets(), which does NOT
return `true` for errors.
Since all the callers of vim_fgets() probably expect it to work as it does in
Vim (and not as it says), it now returns the same values as the Vim
implementation.
Fixes#8227
Problem: Loading file type detection slows down startup.
Solution: Store the last pattern of an autocommand event to make appending
quicker.
462455ee8b
Problem: Cannot detect Bazel BUILD files on some systems.
Solution: Check for BUILD after script checks. (Issue vim/vim#1340)
39170e2d97
vim-patch:8.0.1283: test 86 fails under ASAN
Problem: Loading file type detection slows down startup.
Solution: Move functions to an autoload script.
851ee6c3da
---
vim-patch:8.0.0635
Problem: When 'ignorecase' is set script detection is inaccurate.
Solution: Enforce matching case for text. (closes#1753)
Should actually be silencing that for the sake of the case when `long` is
actually not 64-bit. But it appears that Vim had already defined maximal line
number. And even declared that exact value invalid, so no need in silencing.
Problems:
- In two places in shada_read_when_writing() memory just was not freed. Both
places were verified to cause test failures.
- Numbered marks got assigned incorrect (off-by-one compared to position in the
array) numbers in replace_numbered_mark.
- It was possible to have non-continuously populated array of numbered marks
which messed up code for merging them.
(Note about tests: marks with additional data are always compared different when
merging, that caused some confusion regarding why test did not work the way
I expected.)
closes#8196
For historical reasons, uint64_t and friends are defined both as
typedefs and macros. Some platforms that do that define the macros as
identity (#define uint64_t uint64_t), others like NetBSD define to the
backing type (#define uint64_t __uint64_t). This is normally
transparent, except when multiple levels of macro expansions are used
inconsistently.
MSBuild still returns a non-zero exit code because it detects the word "error" in the stdout which is caused by some of the test names such as api/buf {get,set,del}_line get_line : out-of-bounds is an error.
CMake mailing list thread:
https://cmake.org/pipermail/cmake-developers/2015-October/026775.html
There isn't any good solution for it, so I modified the build script to detect the error message printed by RunTests.cmake.
cmd.exe (shell) is faster and more reliable than powershell (.NET frontend).
It's best for short and basic tests that don't require non-trivial scripting.
cmd.exe doesn't support sleep so use powershell's Start-Sleep as substitute.
Problems so far:
- Marks in the current instance are not adjusted.
- Duplicates are not removed (not that it works in Vim either now, not at
8.0.134 at least).
vim-patch:8.0.0185: system() test fails on MS-Windows
vim-patch:8.0.0197: system() test skips some parts for MS-Windows
vim-patch:8.0.0701: system test failing when using X11 forwarding
Problem: When in Ex mode and an error is caught by try-catch, Vim still
exits with a non-zero exit code.
Solution: Don't set ex_exitval when inside a try-catch. (partly by Christian
Brabandt)
2b7bc567b9
closes#7698
Wrapping a command in double-quotes allows cmd.exe to safely dequote the
entire command as if the user entered the entire command in an
interactive prompt. This reduces the need to escape nested and uneven
double quotes.
The `/s` flag of cmd.exe makes the behaviour more reliable:
:set shellcmdflag=/s\ /c
Before this patch, cmd.exe cannot use cygwin echo.exe (as opposed to
cmd.exe `echo` builtin) even if it is wrapped in double quotes.
Example:
:: internal echo
> cmd /s /c " echo foo\:bar" "
foo\:bar"
:: cygwin echo.exe
> cmd /s /c " "echo" foo\:bar" "
foo:bar
It's a micro-optimization; check path_is_absolute_path(autocmd_fname)
instead.
The main optimization (which is still in place) afforded by Vim 7.2.021
was to avoid resolving <afile> when it is not needed.
During provider dispatch, eval_call_provider() saves global
state--including pointers, such as `autocmd_fname`--into
`provider_caller_scope` which is later restored by f_rpcrequest().
But `autocmd_fname` is special-cased in eval_vars(), for performance
(see Vim patch 7.2.021; this is also the singular purpose of the
`autocmd_fname_full` global. Yay!)
If eval_vars() frees `autocmd_fname` then its provider-RPC-scoped alias
becomes a problem.
Solution: Don't free autocmd_fname in eval_vars(), just copy into it.
closes#5245closes#5617
Reference
------------------------------------------------------------------------
Vim patch 7.2.021
f6dad43c98
Problem: When executing autocommands getting the full file name may be
slow. (David Kotchan)
Solution: Postpone calling FullName_save() until autocmd_fname is used.
vim_dev discussion (2008): "Problem with CursorMoved AutoCommand when
Editing Files on a Remote WIndows Share"
https://groups.google.com/d/msg/vim_dev/kj95weZa_eE/GTgj4aq5sIgJ
Reasoning:
- No need to check for terminal size.
- No need to mess with terminal title.
- Allows old tests to timeout with the rest of the build proceeding.
- Less and less messy output to travis log.
- Opens a path allowing old tests run in parallel. Though last bit needs test
refactoring.
This does not change the behavior but centralizes column size for future use
(like dynamic signcolumn width depending on the maximum number of signs on a line).
The returned value is limited by the size of the `extra` tab in win_line
(currently allows for 18 ASCII characters).
TODO: Raymond Chen explains[1] racy behavior of the
CreateToolhelp32Snapshot approach. Better approach:
> create a job object and put process P in it. Then call
> QueryInformationJobObject with JobObjectBasicProcessIdList to get the
> list of child processes.
[1] "Why is CreateToolhelp32Snapshot returning incorrect parent process IDs all of a sudden?"
https://blogs.msdn.microsoft.com/oldnewthing/20150403-00/?p=44313
XXX: comment at https://stackoverflow.com/q/1173342 :
> Windows recycles PIDs quite fast, you have to be extra careful not
> to kill unrelated processes. These APIs will report PPIDs for long
> dead processes whose PIDs may have been recycled. Check the parent
> start date to make sure it is related to the processes you spawned.
UV_PROCESS_DETACHED compels libuv:uv__process_child_init() to call
setsid() in the child just after fork(). That ensures the process and
its descendants are grouped in a separate session (and process group).
The following jobstart() call correctly groups `sh` and `sleep` in a new
session (and process-group), where `sh` is the "session leader" (and
process-group leader):
:call jobstart(['sh','-c','sleep 60'])
SESN PGRP PID PPID Command
30383 30383 30383 3620 │ ├─ -bash
30383 31432 31432 30383 │ │ └─ nvim -u NORC
30383 31432 31433 30383 │ │ ├─ nvim -u NORC
8105 8105 8105 31432 │ │ └─ sh -c sleep 60
8105 8105 8106 8105 │ │ └─ sleep 60
closes#6530
ref: https://stackoverflow.com/q/1046933
ref: https://unix.stackexchange.com/a/404065
Helped-by: Marco Hinz <mh.codebro+github@gmail.com>
Discussion
------------------------------------------------------------------------
On my linux box before this patch, the termclose_spec.lua:'kills job
trapping SIGTERM' test indirectly causes cmake/busted to wait for 60s.
That's because the test spawns a `sleep 60` descendant process which
hangs around even after nvim exits: nvim killed the parent PID, but not
PGID (process-group), so the grandchild "reparented" to init (PID 1).
Session contains processes (and process-groups) which are logically part
of the same "login session". Process-group is a set of
logically/informally-related processes within a session; for example,
shells assign a process group to each "job". Session IDs and PGIDs both
have type pid_t (like PIDs).
These OS-level mechanisms are, as usual, legacy accidents whose purpose
is upheld by convention and folklore. We can use session-level grouping
(setsid), or we could use process-group-level grouping (setpgid).
Vim uses setsid() if available, otherwise setpgid(0,0).
Windows
------------------------------------------------------------------------
UV_PROCESS_DETACHED on win32 sets CREATE_NEW_PROCESS_GROUP flag.
But uv_kill() does not kill the process-group:
https://github.com/nodejs/node/issues/3617
Ideas:
- Set UV_PROCESS_DETACHED (CREATE_NEW_PROCESS_GROUP), then call
GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, pid)
- Maybe won't work because MSDN says "Only processes that share the
same console as the calling process receive the signal."
https://docs.microsoft.com/en-us/windows/console/generateconsolectrlevent
But CREATE_NEW_PROCESS_GROUP creates a new console ...
ref https://stackoverflow.com/q/1453520
- Group processes within a "job". libuv does that *globally* for
non-detached processes: uv__init_global_job_handle.
- Iterate through CreateToolhelp32Snapshot().
- https://stackoverflow.com/q/1173342
- Vim does this, see terminate_all()
Update vim_diff.txt with :lmap differences, update documentation on
'keymap', and add tests.
The tests added are to demonstrate the behaviour specified in the
documentation of :loadkeymap.
This means that the major way that :lmap mappings are applied works as
one would expect with macros.
This also means that having a translation with 'keymap' does not
preclude using mappings in insert mode with :imap.
There is some behaviour that we keep with the recent changes, and some
behaviour that we change.
Instetad of having one failing test covering all behaviour, we split
the test into two.
If the mental model of :lmap mappings is a translation between your
keyboard and vim proper, then they should take preference over :imap
(and other) mappings. This patch makes that happen.
The mental model of :lmap and 'keymap' is of a transformation done
before anything else. Hence when recording a macro, or writing to a
scriptfile, the transformed keys should be recorded instead of the keys
before the transformation.
vim-patch:8.0.0262: Farsi support is barely tested
Problem: Farsi support is barely tested.
Solution: Add more tests for Farsi. Clean up the code.
ddf662a1c8
vim-patch:8.0.0263: Farsi support is not tested enough
Problem: Farsi support is not tested enough.
Solution: Add more tests for Farsi. Clean up the code.
80627cf51f
macOS travis builds recently started failing (travis caches were cleared
recently, maybe related). python2 is reasonably covered by linux CI. Not
going to waste time on it for macOS CI.
==> Installing python@2
==> Downloading https://homebrew.bintray.com/bottles/python@2-2.7.14_3.el_capita
==> Pouring python@2-2.7.14_3.el_capitan.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3-2
Target /usr/local/bin/2to3-2
is a symlink belonging to python. You can unlink it:
brew unlink python
To force the link and overwrite all conflicting files:
brew link --overwrite python@2
To list all files that would be deleted:
brew link --overwrite --dry-run python@2
Possible conflicting files are:
/usr/local/bin/2to3-2 -> /usr/local/Cellar/python/2.7.12_1/bin/2to3-2
/usr/local/bin/2to3-2.7 -> /usr/local/Cellar/python/2.7.12_1/bin/2to3-2.7
/usr/local/bin/idle -> /usr/local/Cellar/python/2.7.12_1/bin/idle
...
The MSVC_32 currently hangs. When MSVC becomes the primary Windows
target, we can enable MSVC_32 and retire one of the mingw builds. In
the meantime it adds too much time.
Infinite timeout results in hangs which waste time. If some test needs
longer than 10s to wait for a message, it should specify the timeout
explicitly.
This will allow users to use AppImageUpdate to update their AppImage.
It requires publishing the created zsync file alongside the appimage
file for the releases.
Problem: Getting name of cleared highlight group is wrong. (Matt Wozniski)
Solution: Only skip over cleared names for completion. (closesvim/vim#1592)
Also fix that a cleared group causes duplicate completions.
c96272e30e
I have `g:python3_host_prog` set to the system Python, where a package
is also installed to provide the "neovim" module.
`:checkhealth provider` however displays a warning for this:
> Your virtualenv is not set up optimally.
This is because /usr/bin/python is not in /home/user/.pyenv.
I think this warning should not get displayed if host_prog_var exists.
It goes back to the initial commit (20447ba09), and is maybe only
missing the `!` there as with the previous commit.
Full output:
```
- INFO: pyenv: /home/user/.pyenv/libexec/pyenv
- INFO: pyenv root: /home/user/.pyenv
- INFO: Using: g:python3_host_prog = "/usr/bin/python"
- WARNING: Your virtualenv is not set up optimally (/usr/bin/python is not in /home/user/.pyenv).
- ADVICE:
- Create a virtualenv specifically for Neovim and use `g:python3_host_prog`. This will avoid the need to install Neovim's Python module in each virtualenv.
- WARNING: $VIRTUAL_ENV exists but appears to be inactive. This could lead to unexpected results.
- ADVICE:
- If you are using Zsh, see: http://vi.stackexchange.com/a/7654
- INFO: Executable: /usr/bin/python
- INFO: Python3 version: 3.6.4
- INFO: python-neovim version: 0.2.1
- OK: Latest python-neovim is installed: 0.2.1
```
Problem: Completion for :match does not show "none" and other missing
highlight names.
Solution: Skip over cleared entries before checking the index to be at the
end.
15eedf1d62
vim-patch:8.0.0234: crash when using put in Visual mode
Problem: When several lines are visually selected and one of them is short,
using put may cause a crash. (Axel Bender)
Solution: Check for a short line. (Christian Brabandt)
941c12da3c
vim-patch:8.0.0236: gcc complains about uninitialized variable
Problem: Gcc complains that a variable may be used uninitialized. Confusion
between variable and label name. (John Marriott)
Solution: Initialize it. Rename end to end_lnum.
6a717f17ec
vim-patch:8.0.0225: put in Visual block mode terminates early
Problem: When a block is visually selected and put is used on the end of
the selection only one line is changed.
Solution: Check for the end properly. (Christian Brabandt, neovim issue
5781)
9957a10d0f
Homebrew changed a few formulae to meet their standards. "python3" was renamed
to "python", and "python2" to "python@2".
As for why, read this announcement: https://brew.sh/2018/01/19/homebrew-1.5.0
Since we install Python 3 via homebrew anyway, we now do the same for Python 2
as well. We do that because the system Python 2 of macOS comes without pip
installed and this way seems cleaner than doing "sudo easy_install pip".
The Python 2 formula is keg-only now, so it doesn't interfere with the system
Python 2. Therefore we have to add its executables to $PATH ourselves.
LuaRocks bundles an outdated wget.exe for downloading packages on Windows. It is too old to support GitHub's TLS, so this patch will replace it with curl.
With MSVC, STDOUT_FILENO and STDERR_FILENO are defined as function calls instead of constants, meaning they can't be assigned to enum values. The enum was only used in one file, so it has been removed. A definition for STDIN_FILENO has been added that is consistent with the other two definitions.
The following code..
au VimEnter,DirChanged * if filereadable('.git/cscope.out') |
\ exe 'cs add .git/cscope.out' | endif
..would lead to this issue:
Error detected while processing VimEnter Auto commands for "*":
cs_read_prompt EOF: Interrupted system call
Error detected while processing VimEnter Auto commands for "*":
E262: error reading cscope connection 0
A signal, in this case SIGCHLD, during a system call leads to errno being set
to EINTR. Ignore it.
This is merely a workaround for the time being. We don't block SIGCHLD signals,
since they're needed by libuv. The proper fix would be to rewrite if_cscope.c to
use libuv for handling processes.
Problem: If cscope fails a search Vim may hang.
Solution: Bail out when a search error is encountered. (Safouane Baroudi,
closesvim/vim#2598)
1274d33493
Tracking master subjects us to breakages (as happened when
luacheck-scm-1.rockspec got renamed to luacheck-dev-1.rockspec) and
makes older releases unbuildable when that happens.
Currently writedelay shows the sequence of characters that are sent to
the UI/TUI module. Here nvim has already applied an optimization: when
attempting to put a char in a screen cell, if the same char already was
there with the same attributes, UI output is disabled. When debugging
redrawing it it sometimes more useful to inspect the redraw stream one
step earlier, what region of the screen nvim actually is recomputing
from buffer contents (win_line) and from evaluating statusline
expressions.
Take the popupmenu as an example. When closing the popupmenu (in the
TUI), currently 'writedelay' looks like vim only is redrawing the region
which the pum covered. This is not what happens internally: vim redraws
the entire screen, even if only outputs the changed region.
This commit allows negative values of 'writedelay', which causes a delay
for all redrawn characters, even if the character already was displayed
by the UI before.
Most fonts should have these by now. Both are a significant visual
improvement.
- Vertical connecting bar `│` is used by tmux, pstree, Windows 7 cmd.exe
and nvim-qt.exe.
- Middle dot `·` works on Windows 7 cmd.exe, nvim-qt.exe.
For reference: tmux uses these chars to draw lines: │ ├ ─
`g:loaded_python3_provider` gets set when the autoload file is sourced,
but this might error out, e.g. with deoplete:
[deoplete] Failed to load python3 host. You can try to see what happened by starting nvim with $NVIM_PYTHON_LOG_FILE set and opening the generated log file. Also, the host stderr is available in messages.
[deoplete] function remote#define#FunctionBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[13]..provider#Poll, line 14
[deoplete] deoplete requires Python3 support("+python3").
[deoplete] deoplete failed to load. Try the :UpdateRemotePlugins command and restart Neovim. See also :checkhealth.
It refers to `:checkhealth` from there explicitly, which would then
(without this patch) say that Python 3 is disabled.
This patch changes the reported info to include that it might have been
disabled due to some error, and keeps on going.
This helps to figure out what the problem is, e.g. in my case I have
lua51-mpack installed to be used with luajit, but it is broken (missing
libmpack).
With this patch you get:
-- Checking Lua interpreter /usr/bin/luajit
/usr/bin/luajit: error loading module 'mpack' from file '/usr/lib/lua/5.1/mpack.so':
libmpack.so.0: cannot open shared object file: No such file or directory
stack traceback:
[C]: at 0x55fcf0166fb0
[C]: in function 'require'
(command line):1: in main chunk
[C]: at 0x55fcf01188a0
-- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.1
/usr/bin/lua5.1: error loading module 'mpack' from file '/usr/lib/lua/5.1/mpack.so':
libmpack.so.0: cannot open shared object file: No such file or directory
stack traceback:
[C]: ?
[C]: in function 'require'
(command line):1: in main chunk
[C]: ?
-- [/usr/bin/lua5.1] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.2
/usr/bin/lua5.2: (command line):1: module 'mpack' not found:
no field package.preload['mpack']
no file '/usr/share/lua/5.2/mpack.lua'
no file '/usr/share/lua/5.2/mpack/init.lua'
no file '/usr/lib/lua/5.2/mpack.lua'
no file '/usr/lib/lua/5.2/mpack/init.lua'
no file './mpack.lua'
no file '/usr/lib/lua/5.2/mpack.so'
no file '/usr/lib/lua/5.2/loadall.so'
no file './mpack.so'
stack traceback:
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
-- [/usr/bin/lua5.2] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua
/usr/bin/lua: (command line):1: module 'mpack' not found:
no field package.preload['mpack']
no file '/usr/share/lua/5.3/mpack.lua'
no file '/usr/share/lua/5.3/mpack/init.lua'
no file '/usr/lib/lua/5.3/mpack.lua'
no file '/usr/lib/lua/5.3/mpack/init.lua'
no file './mpack.lua'
no file './mpack/init.lua'
no file '/usr/lib/lua/5.3/mpack.so'
no file '/usr/lib/lua/5.3/loadall.so'
no file './mpack.so'
stack traceback:
[C]: in function 'require'
(command line):1: in main chunk
[C]: in ?
-- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim
CMake Error at CMakeLists.txt:459 (message):
A suitable Lua interpreter was not found.
While this makes it more verbose for the expected error case ("module
'mpack' not found"), the behavior before this patch hides too much.
This is the old output:
-- Checking Lua interpreter /usr/bin/luajit
-- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.1
-- [/usr/bin/lua5.1] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua5.2
-- [/usr/bin/lua5.2] The 'mpack' lua package is required for building Neovim
-- Checking Lua interpreter /usr/bin/lua
-- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim
CMake Error at CMakeLists.txt:459 (message):
A suitable Lua interpreter was not found.
This is for when the whole configuration runs (i.e. after `make
distclean`), afterwards only one Lua interpreter gets checked only.
Problem: When a block is visually selected and put is used on the end of
the selection only one line is changed.
Solution: Check for the end properly. (Christian Brabandt, neovim issue
5781)
9957a10d0f
Note: code change was covered by c2a1821611
Problem: When a multi-byte character ends in a zero byte, putting blockwise
text puts it before the character instead of after it.
Solution: Use int instead of char for the character under the cursor.
(Luchr, closesvim/vim#1403) Add a test.
c81299684b
vim-patch:8.0.0214: leaking memory when syntax cluster id is unknown
Problem: Leaking memory when syntax cluster id is unknown. (Coverity)
Solution: Free the memory.
d7a96151e0
Only remove the directory contents. If the directory itself is removed,
then `sudo make install` creates a root-owned …/doc/ directory. That
breaks the next non-root build.
This was an accident of 0b1904d835.
Note: the following does not work, because it misses renamed help files
(which would no longer be in the build-tree definition)
COMMAND ${CMAKE_COMMAND} -E remove ${BUILDDOCFILES} ${GENERATED_HELP_TAGS}
- echo "" does not hang in powershell
- cmd.exe's echo command does not hang.
- job tests default to powershell (WHY?)
- wait 5 seconds for powershell to create an empty file
- powershell is slow
- cannot reliably validate the id returned by jobstart via jobpid, jobstop
- if using cmd.exe, waiting for a second should be enough
- remaining job tests are unreliable in Windows because any build can pass/fail
for same conditions without changes, especially if the error is in stderr
Problem: The buffer used to store a key name theoreticaly could be too
small. (Coverity)
Solution: Count all possible modifier characters. Add a check for the
length just in case.
423977d3ce
It was added in the parent commit, but ended up not being used. And
I can't think of a case where it will be used: instead we would probably
want to generalize expect_msg_seq() if necessary.
❯ git log --oneline v2.0.0...v1.2.1
e3b16d6 (HEAD -> master, tag: v2.0.0, origin/master, origin/HEAD) version 2.0.0
6f0037b (origin/wide-int) update README with build instructions / prerequisites
f40c97a explicitly mention the new "wide integer" format in the man pages
37aa305 use ncurses*-config to get TERMINFO_DIRS if possible
2461ee1 use perl instead of sed hackery to create unibilium.pc
23e9dea don't cast between pointer types of different alignments
1b5b8fd add basic test for wide format
cfe4216 add xterm-256color; regenerate static tests from ncurses 6.1
6e55e75 escape backslashes properly
42f3cdd add 32 bit number support (wide terminfo format)
73385ba unibi-dump: accept a filename as argument
ec9ef0a don't pass NULL to memcpy
b42315b (origin/typecheck) make unibi_var_t slightly more type-safe
If `jobstart()` fails, then the subsequent `rpcrequest()` will throw due
to an invalid channel id. This causes `job.stderr` not to exist, so we
throw another exception when trying to dump the job's stderr.
Error detected while processing function remote#define#AutocmdBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require:
line 22:
E716: Key not present in Dictionary: stderr
This obfuscates the actual problem.
Problem: Splitting a 'winfixwidth' window vertically makes it one column
smaller. (Dominique Pelle)
Solution: Add one to the width for the separator.
38e3483637
Problem: Linebreak tests are old style.
Solution: Turn the tests into new style. Share utility functions. (Ozaki
Kiichi, closesvim/vim#1444)
544d3bc9f0
Problem: The ";" command does not work after characters with a lower byte
that is NUL.
Solution: Properly check for not having a previous character. (Hirohito
Higashi)
454709baff
Needed for later Vim patches.
Stub test_alot_latin.vim to avoid merge-conflict noise.
vim-patch:7.4.1700
vim-patch:7.4.1734
vim-patch:7.4.1740
vim-patch:7.4.2086
vim-patch:7.4.2223
vim-patch:8.0.0250
Problem: Some tests have a one or three second wait.
Solution: Reset the 'showmode' option. Use a test time of one to disable
sleep after an error or warning message.
e5f2a075e3
Problem: When one channel test fails others fail as well.
Solution: Stop the job after a failure. Also add a couple of tests to the
list of flaky tests.
24820691e6
Problem: The remote_peek() test fails on MS-Windows.
Solution: Check for pending messages. Also report errors in the first run if
a flaky test fails twice.
15e737f768
This test exposes a bug (present on current master).
Steps to reproduce:
CC=clang make CMAKE_BUILD_TYPE=Debug CMAKE_EXTRA_FLAGS="-DCLANG_ASAN_UBSAN=ON"
export ASAN_SYMBOLIZER_PATH=/usr/lib/llvm-5.0/bin/llvm-symbolizer
TEST_FILE=test_autocmd.res make oldtest
==3668==ERROR: AddressSanitizer: heap-use-after-free on address 0x6260001411c8 at pc 0x000000a38a47 bp 0x7fff9982ee50 sp 0x7fff9982ee48
READ of size 4 at 0x6260001411c8 thread T0
0 0xa38a46 in _typval_encode_nothing_convert_one_value /home/vagrant/neovim/build/../src/nvim/eval/typval_encode.c.h:320:15
1 0xa340d5 in encode_vim_to_nothing /home/vagrant/neovim/build/../src/nvim/eval/typval_encode.c.h:830:9
2 0xa0ad63 in tv_clear /home/vagrant/neovim/build/../src/nvim/eval/typval.c:2189:25
3 0x85d584 in vars_clear_ext /home/vagrant/neovim/build/../src/nvim/eval.c:18894:9
4 0x7efac9 in vars_clear /home/vagrant/neovim/build/../src/nvim/eval.c:18871:3
5 0x7ef471 in eval_clear /home/vagrant/neovim/build/../src/nvim/eval.c:638:3
6 0xf80a7c in free_all_mem /home/vagrant/neovim/build/../src/nvim/memory.c:676:3
7 0x12789dc in mch_exit /home/vagrant/neovim/build/../src/nvim/os_unix.c:152:3
8 0xe85039 in getout /home/vagrant/neovim/build/../src/nvim/main.c:671:3
9 0xbb4496 in ex_quit_all /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:6051:5
10 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
11 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
12 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
13 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
14 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
15 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
16 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
17 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
18 0xb17fdd in do_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2973:3
19 0xb14630 in cmd_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2718:14
20 0xb14727 in ex_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2699:3
21 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
22 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
23 0xb34015 in do_cmdline_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:280:10
24 0xe829d3 in exe_commands /home/vagrant/neovim/build/../src/nvim/main.c:1702:5
25 0xe708bd in main /home/vagrant/neovim/build/../src/nvim/main.c:524:5
26 0x7f0cd5b7e82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
27 0x44d628 in _start (/home/vagrant/neovim/build/bin/nvim+0x44d628)
0x6260001411c8 is located 200 bytes inside of 10256-byte region [0x626000141100,0x626000143910)
freed by thread T0 here:
0 0x50df60 in __interceptor_cfree.localalias.0 (/home/vagrant/neovim/build/bin/nvim+0x50df60)
1 0xf7dbe4 in xfree /home/vagrant/neovim/build/../src/nvim/memory.c:133:3
2 0x676577 in free_buffer /home/vagrant/neovim/build/../src/nvim/buffer.c:749:5
3 0x66e15b in close_buffer /home/vagrant/neovim/build/../src/nvim/buffer.c:590:5
4 0x67a835 in do_buffer /home/vagrant/neovim/build/../src/nvim/buffer.c:1216:9
5 0x681a1d in do_bufdel /home/vagrant/neovim/build/../src/nvim/buffer.c:945:16
6 0xb9cd72 in ex_bunload /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:4585:17
7 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
8 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
9 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
10 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
11 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
12 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
13 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
14 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
15 0x8646b1 in ex_execute /home/vagrant/neovim/build/../src/nvim/eval.c:19478:7
16 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
17 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
18 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
19 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
20 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
21 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
22 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
23 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
24 0xb17fdd in do_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2973:3
25 0xb14630 in cmd_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2718:14
26 0xb14727 in ex_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2699:3
27 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
28 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
29 0xb34015 in do_cmdline_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:280:10
previously allocated by thread T0 here:
0 0x50e340 in calloc (/home/vagrant/neovim/build/bin/nvim+0x50e340)
1 0xf7dc97 in xcalloc /home/vagrant/neovim/build/../src/nvim/memory.c:147:15
2 0x67eb65 in buflist_new /home/vagrant/neovim/build/../src/nvim/buffer.c:1641:11
3 0xa8fdcc in do_ecmd /home/vagrant/neovim/build/../src/nvim/ex_cmds.c:2221:13
4 0x683b21 in empty_curbuf /home/vagrant/neovim/build/../src/nvim/buffer.c:1031:12
5 0x67a098 in do_buffer /home/vagrant/neovim/build/../src/nvim/buffer.c:1196:14
6 0x68173f in do_bufdel /home/vagrant/neovim/build/../src/nvim/buffer.c:927:11
7 0xb9cd72 in ex_bunload /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:4585:17
8 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
9 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
10 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
11 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
12 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
13 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
14 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
15 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
16 0x8646b1 in ex_execute /home/vagrant/neovim/build/../src/nvim/eval.c:19478:7
17 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
18 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
19 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
20 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
21 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
22 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
23 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
24 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
25 0xb17fdd in do_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2973:3
26 0xb14630 in cmd_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2718:14
27 0xb14727 in ex_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2699:3
28 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
29 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
SUMMARY: AddressSanitizer: heap-use-after-free /home/vagrant/neovim/build/../src/nvim/eval/typval_encode.c.h:320:15 in _typval_encode_nothing_convert_one_va
lue
Shadow bytes around the buggy address:
0x0c4c800201e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4c800201f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4c80020200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4c80020210: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4c80020220: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c4c80020230: fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd
0x0c4c80020240: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4c80020250: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4c80020260: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4c80020270: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c4c80020280: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==3668==ABORTING
This test exposes a bug (present on current master) in ins_char_bytes()
or somewhere earlier.
Steps to reproduce:
inoremap <C-D> <Del>
enew!
exe "normal a\nabcdefghi\njk\tlmn\n opq rst\n\<C-D>uvwxyz"
call cursor(1,1)
exe "normal gR0\<C-D> 1\nA\nBCDEFGHIJ\n\tKL\nMNO\nPQR"
or run `TEST_FILE=test_visual.res make oldtest`.
Executing Test_virtual_replace()
2 buffers wiped out=================================================================
==31341==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c4f34 at pc 0x0000004f7971 bp 0x7ffdf87bb190 sp 0x7ffdf87ba940
WRITE of size 1 at 0x6020000c4f34 thread T0
0 0x4f7970 in __asan_memmove (/home/vagrant/neovim/build/bin/nvim+0x4f7970)
1 0xfde7a3 in ins_char_bytes /home/vagrant/neovim/build/../src/nvim/misc1.c:1488:3
2 0xfdef41 in ins_char /home/vagrant/neovim/build/../src/nvim/misc1.c:1403:3
3 0x79dd03 in insertchar /home/vagrant/neovim/build/../src/nvim/edit.c:5285:7
4 0x7be70f in insert_special /home/vagrant/neovim/build/../src/nvim/edit.c:5071:5
5 0x7bd94a in insert_handle_key /home/vagrant/neovim/build/../src/nvim/edit.c:1229:7
6 0x76df14 in insert_execute /home/vagrant/neovim/build/../src/nvim/edit.c:764:10
7 0x173cda9 in state_enter /home/vagrant/neovim/build/../src/nvim/state.c:67:26
8 0x77601d in insert_enter /home/vagrant/neovim/build/../src/nvim/edit.c:458:5
9 0x76986e in edit /home/vagrant/neovim/build/../src/nvim/edit.c:1327:3
10 0x1118661 in invoke_edit /home/vagrant/neovim/build/../src/nvim/normal.c:7591:7
11 0x10e60bc in nv_Replace /home/vagrant/neovim/build/../src/nvim/normal.c:6070:7
12 0x10f235d in nv_g_cmd /home/vagrant/neovim/build/../src/nvim/normal.c:6541:5
13 0x10c0eaa in normal_execute /home/vagrant/neovim/build/../src/nvim/normal.c:1136:3
14 0x10b8444 in normal_cmd /home/vagrant/neovim/build/../src/nvim/normal.c:7995:9
15 0xb80982 in exec_normal /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:8197:5
16 0xb8065b in exec_normal_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:8180:3
17 0xbb08df in ex_normal /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:8098:7
18 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
19 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
20 0x8646b1 in ex_execute /home/vagrant/neovim/build/../src/nvim/eval.c:19478:7
21 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
22 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
23 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
24 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
25 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
26 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
27 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
28 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
29 0x8646b1 in ex_execute /home/vagrant/neovim/build/../src/nvim/eval.c:19478:7
30 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
31 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
32 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
33 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
34 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
35 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
36 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
37 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
38 0xb17fdd in do_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2973:3
39 0xb14630 in cmd_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2718:14
40 0xb14727 in ex_source /home/vagrant/neovim/build/../src/nvim/ex_cmds2.c:2699:3
41 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
42 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
43 0xb34015 in do_cmdline_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:280:10
44 0xe829d3 in exe_commands /home/vagrant/neovim/build/../src/nvim/main.c:1702:5
45 0xe708bd in main /home/vagrant/neovim/build/../src/nvim/main.c:524:5
46 0x7f0012a7782f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
47 0x44d628 in _start (/home/vagrant/neovim/build/bin/nvim+0x44d628)
0x6020000c4f34 is located 0 bytes to the right of 4-byte region [0x6020000c4f30,0x6020000c4f34)
allocated by thread T0 here:
0 0x50e128 in malloc (/home/vagrant/neovim/build/bin/nvim+0x50e128)
1 0xf7d871 in try_malloc /home/vagrant/neovim/build/../src/nvim/memory.c:87:15
2 0xf7da99 in xmalloc /home/vagrant/neovim/build/../src/nvim/memory.c:121:15
3 0xfde3c7 in ins_char_bytes /home/vagrant/neovim/build/../src/nvim/misc1.c:1473:18
4 0xfdef41 in ins_char /home/vagrant/neovim/build/../src/nvim/misc1.c:1403:3
5 0x79dd03 in insertchar /home/vagrant/neovim/build/../src/nvim/edit.c:5285:7
6 0x7be70f in insert_special /home/vagrant/neovim/build/../src/nvim/edit.c:5071:5
7 0x7bd94a in insert_handle_key /home/vagrant/neovim/build/../src/nvim/edit.c:1229:7
8 0x76df14 in insert_execute /home/vagrant/neovim/build/../src/nvim/edit.c:764:10
9 0x173cda9 in state_enter /home/vagrant/neovim/build/../src/nvim/state.c:67:26
10 0x77601d in insert_enter /home/vagrant/neovim/build/../src/nvim/edit.c:458:5
11 0x76986e in edit /home/vagrant/neovim/build/../src/nvim/edit.c:1327:3
12 0x1118661 in invoke_edit /home/vagrant/neovim/build/../src/nvim/normal.c:7591:7
13 0x10e60bc in nv_Replace /home/vagrant/neovim/build/../src/nvim/normal.c:6070:7
14 0x10f235d in nv_g_cmd /home/vagrant/neovim/build/../src/nvim/normal.c:6541:5
15 0x10c0eaa in normal_execute /home/vagrant/neovim/build/../src/nvim/normal.c:1136:3
16 0x10b8444 in normal_cmd /home/vagrant/neovim/build/../src/nvim/normal.c:7995:9
17 0xb80982 in exec_normal /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:8197:5
18 0xb8065b in exec_normal_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:8180:3
19 0xbb08df in ex_normal /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:8098:7
20 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
21 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
22 0x8646b1 in ex_execute /home/vagrant/neovim/build/../src/nvim/eval.c:19478:7
23 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
24 0xb2dd03 in do_cmdline /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:609:20
25 0x845302 in call_user_func /home/vagrant/neovim/build/../src/nvim/eval.c:21332:3
26 0x81097b in call_func /home/vagrant/neovim/build/../src/nvim/eval.c:6358:11
27 0x825778 in get_func_tv /home/vagrant/neovim/build/../src/nvim/eval.c:6120:11
28 0x81e361 in ex_call /home/vagrant/neovim/build/../src/nvim/eval.c:2735:9
29 0xb4ba9c in do_one_cmd /home/vagrant/neovim/build/../src/nvim/ex_docmd.c:2242:5
SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/vagrant/neovim/build/bin/nvim+0x4f7970) in __asan_memmove
Shadow bytes around the buggy address:
0x0c0480010990: fa fa fd fa fa fa fd fa fa fa 00 fa fa fa 01 fa
0x0c04800109a0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c04800109b0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c04800109c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c04800109d0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
=>0x0c04800109e0: fa fa 05 fa fa fa[04]fa fa fa fa fa fa fa fa fa
0x0c04800109f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480010a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480010a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480010a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0480010a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==31341==ABORTING
Problem: Invalid memory access in read_redo(). (gy741)
Solution: Convert the replacement character back from a negative number to
CR or NL. (hint by Dominique Pelle, closesvim/vim#2616)
f12519dec8
Test_edit_08() depends on special-case handling in has_compl_option()
and redrawing() which are in Vim but are not wanted in Nvim. Using a Lua
test instead of depending on workarounds in the core to make the VimL
test work.
Problem: Still interference between test functions.
Solution: Clear autocommands. Wipe all buffers. Fix tests that depend on a
specific start context.
cf1ba35fc2
Problem: The conf filetype detection is done before ftdetect scripts from
packages that are added later.
Solution: Add the FALLBACK argument to :setfiletype. (closesvim/vim#1679,
closesvim/vim#1693)
3e54569b17
Problem: When typing a search pattern CTRL-G and CTRL-T are ignored when
there is typeahead.
Solution: Don't pass SEARCH_PEEK and don't call char_avail(). (haya14busa,
closesvim/vim#2233)
f8e8c0643b
Problem: :argadd without argument can't handle space in file name. (Harm te
Hennepe)
Solution: Escape the space. (Yasuhiro Matsumoto, closesvim/vim#1917)
398ee7326b
Problem: Using ":%argdel" while the argument list is already empty gives an
error. (Pavol Juhas)
Solution: Don't give an error. (closesvim/vim#1546)
69a92fb5ae
Also:
vim-patch:8.0.0473
We have a ported Lua version, but we should also keep the Vim version
around to make merging easier.
---
vim-patch:8.0.0723: arglist test fails if file name case is ignored
Problem: Arglist test fails if file name case is ignored.
Solution: Wipe existing buffers, check for fname_case property.
9b50bba643
Problem: Segfault with QuitPre autocommand closes the window. (Marek)
Solution: Check that the window pointer is still valid. (Christian Brabandt,
closesvim/vim#1817)
0ea5070d79
Problem: Crash with nasty autocommand. (gy741, Dominique Pelle)
Solution: Check that the new current buffer isn't wiped out. (closesvim/vim#2447)
9bca805ec4
Problem: Crash when closing the quickfix window in a FileType autocommand
that triggers when the quickfix window is opened.
Solution: Save the new value before triggering the OptionSet autocommand.
Add the "starting" flag to test_override() to make the text work.
182a17b1e8
Problem: The OptionSet autocommand event is not triggered when entering
diff mode.
Solution: use set_option_value() instead of setting the option directly.
Change the tests from old to new style. (Christian Brabandt)
04f62f881c
Problem: Still quite a few old style tests.
Solution: Convert old to new style tests. (Yegappan Lakshmanan)
Avoid ringing the bell while running tests.
4a6fcf8047
Problem: When a test fails and test.log is created, Test_edit_CTRL_I
matches it instead of test1.in.
Solution: Match with runtest.vim instead.
c537947100
Problem: Still many old style tests.
Solution: Convert several tests to new style. (Yegappan Lakshmanan)
4a137b4586
vim-patch:8.0.0862: file size test fails on MS-Windows
Problem: File size test fails on MS-Windows.
Solution: Set fileformat after opening new buffer. Strip CR.
07c043af5f
Problem: Using a text object to select quoted text fails when 'selection'
is set to "exclusive". (Guraga)
Solution: Swap cursor and visual start position. (Christian Brabandt,
closesvim/vim#1687)
c5e2b040b4
Problem: The ~ character is not escaped when adding to the search pattern
with CTRL-L. (Ramel Eshed)
Solution: Escape the character. (Christian Brabandt)
a693d0584b
Make HlAttr contain highlighting state for both color modes (cterm and rgb).
This allows us to implement termguicolors completely in the TUI.
Simplify some logic duplicated between ui.c and screen.c. Also avoid
some superfluous highlighting reset events.
Problem: Searchpair() might return an invalid value on timeout.
Solution: When the second search times out, do not accept a match from the
first search. (Daniel Hahler, closesvim/vim#2552)
9d32276b52
The old behavior is probably not justified, for the usual reason:
terminal buffers may have interactive processes, so cursor placement is
arbitrary, therefore tracking it in the jumplist is useless (or worse).
N.B.: per the docstring for `checkpcmark()` it looks like we were
calling `checkpcmark()` and `setpcmark()` in the wrong order.
closes#3723
Lua (not LuaJIT) complains about the "^[[" strings inside the expect,
since it sees them as nested quotes. Change the quoting to [=[ ]=] to
avoid the issue.
Use unique filenames to avoid test conflicts.
Use read_file() instead of io.popen(), to ensures the file is closed.
Use helpers.rmdir(), it is far more robust than lfs.
closes#7911
vim-patch:8.0.0175: setting language on MS-Windows does not always work
vim-patch:8.0.0185: system() test fails on MS-Windows
vim-patch:8.0.1435: memory leak in test_arabic
vim-patch:8.0.0424: compiler warnings on MS-Windows
vim-patch:8.0.0434: clang version not correctly detected
vim-patch:8.0.0458: potential crash if adding list or dict to dict fails
Problem: Third item of synconcealed() changes too often. (Dominique Pelle)
Solution: Reset the sequence number at the start of each line.
cc0750dc6ecloses#7589
Fixes#7932
Nvim (tui.c) always enables SGR mouse (TUIData.unibi_ext.enable_mouse).
But if libtermkey sees key_mouse (kmous) in terminfo its terminfo driver
(driver-ti.c) will be activated, which by accident only supports X10
protocol. The libtermkey CSI driver (driver-csi.c), in contrast,
supports SGR.
We can force libtermkey to ignore the terminfo key_mouse entry by
returning NULL in the tui_tk_ti_getstr hook. That forces the CSI driver.
What is the effect of returning NULL from `tui_tk_ti_getstr()`?
- libtermkey `driver-ti.c:load_terminfo()` skips the entry.
- `termkey.c:peekkey()` iterates through all drivers, it finds
`TERMKEY_RES_NONE` for the ti driver and falls back to the CSI driver.
On some versions of macOS, pbcopy doesn't work in tmux <2.6
https://superuser.com/q/231130
Fallback to tmux in that case.
Add a healthcheck for this scenario.
vim-patch:8.0.0358: invalid memory access in C-indent code
Problem: Invalid memory access in C-indent code.
Solution: Don't go over end of empty line. (Dominique Pelle, closesvim/vim#1492)
60629d6425
vim-patch:8.0.0359: 'number' and 'relativenumber' are not properly tested
Problem: 'number' and 'relativenumber' are not properly tested.
Solution: Add tests, change old style to new style tests. (Ozaki Kiichi,
closesvim/vim#1447)
dc9a081712
Per CMAKE docs, CMAKE_HOST_SYSTEM_VERSION is the result of `uname -r`:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_HOST_SYSTEM_VERSION.html?highlight=uname
A numeric version string for the system. On systems that support
uname, this variable is set to the output of uname -r. On other
systems this is set to major-minor version numbers.
On Windows it is something like "6.1", so it won't match ".*-Microsoft".
Closes#7329
Problem: When 'wildmenu' is set and 'wildmode' has "longest" then the first
file name is highlighted, even though the text shows the longest
match.
Solution: Do not highlight the first match. (LemonBoy, closesvim/vim#1602)
ef8eb08978
Vim's src/testdir has more directories in it, so the "./samples/" item
happens to have a space in front of it. This isn't relevant to the
test, so just elide the space for our case.
This reverts commit f7fe3012204169f22412194a78f196ffc72bb8c3.
Fails on QuickBuild because it uses a non-local path.
Need a environment-agnostic solution
ui_bridge:ui_bridge_stop() calls ui_detach_impl() last, so the check for
ui_active() in ui:ui_refresh() doesn't help: tui_main() already freed
the `ui` object.
There is a race between ui_bridge_stop (thread T0) and tui_main (thread T1).
UIBridgeData.stopped could be set while ui_bridge_stop() is in the
middle of loop_poll_events(), which may invoke tui_scheduler() on T0.
The pointers in tui_scheduler() may be invalid by then.
Solution(?): Use the `UI.data` field as a "stopped" flag and check it in
tui_scheduler().
ASAN use-after-free report observed in #7908:
= ==20066==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000000cd0 at pc 0x00000182abed bp 0x7ffe23b07070 sp 0x7ffe23b07068
= READ of size 8 at 0x611000000cd0 thread T0
= 0 0x182abec in tui_scheduler /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:393:23
= 1 0x1876afd in ui_bridge_update_fg /home/travis/build/neovim/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:205:3
= 2 0x186c130 in ui_resize /home/travis/build/neovim/neovim/src/nvim/ui.c:310:3
= 3 0x146b9c2 in screen_resize /home/travis/build/neovim/neovim/src/nvim/screen.c:7483:3
= 4 0x186a6f0 in ui_refresh /home/travis/build/neovim/neovim/src/nvim/ui.c:284:3
= 5 0x186bbe0 in ui_refresh_event /home/travis/build/neovim/neovim/src/nvim/ui.c:297:3
= 6 0xa2219a in multiqueue_process_events /home/travis/build/neovim/neovim/src/nvim/event/multiqueue.c:150:7
= 7 0xa1bd7f in loop_poll_events /home/travis/build/neovim/neovim/src/nvim/event/loop.c:63:3
= 8 0x1872709 in ui_bridge_stop /home/travis/build/neovim/neovim/src/nvim/ui_bridge.c:121:5
= 9 0x1864247 in ui_builtin_stop /home/travis/build/neovim/neovim/src/nvim/ui.c:143:3
= 10 0x1249ec8 in mch_exit /home/travis/build/neovim/neovim/src/nvim/os_unix.c:140:3
= 11 0xe56ba9 in getout /home/travis/build/neovim/neovim/src/nvim/main.c:671:3
= 12 0xfc4c8f in preserve_exit /home/travis/build/neovim/neovim/src/nvim/misc1.c:2653:3
= 13 0x1247c02 in deadly_signal /home/travis/build/neovim/neovim/src/nvim/os/signal.c:137:3
= 14 0x1247921 in on_signal /home/travis/build/neovim/neovim/src/nvim/os/signal.c:162:9
= 15 0xa35618 in signal_event /home/travis/build/neovim/neovim/src/nvim/event/signal.c:47:3
= 16 0xa2219a in multiqueue_process_events /home/travis/build/neovim/neovim/src/nvim/event/multiqueue.c:150:7
= 17 0xa1bd7f in loop_poll_events /home/travis/build/neovim/neovim/src/nvim/event/loop.c:63:3
= 18 0x1237bd6 in input_poll /home/travis/build/neovim/neovim/src/nvim/os/input.c:349:3
= 19 0x123334f in inbuf_poll /home/travis/build/neovim/neovim/src/nvim/os/input.c:372:24
= 20 0x123316d in os_inchar /home/travis/build/neovim/neovim/src/nvim/os/input.c:110:19
= 21 0x170d20e in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:55:13
= 22 0xbd7441 in command_line_enter /home/travis/build/neovim/neovim/src/nvim/ex_getln.c:384:3
= 23 0xbd0a60 in getcmdline /home/travis/build/neovim/neovim/src/nvim/ex_getln.c:1920:10
= 24 0xbdb365 in getexline /home/travis/build/neovim/neovim/src/nvim/ex_getln.c:2100:10
= 25 0xb00a6b in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:528:47
= 26 0x10a7837 in nv_colon /home/travis/build/neovim/neovim/src/nvim/normal.c:4552:18
= 27 0x1091e15 in normal_execute /home/travis/build/neovim/neovim/src/nvim/normal.c:1136:3
= 28 0x170d439 in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:67:26
= 29 0x104ee14 in normal_enter /home/travis/build/neovim/neovim/src/nvim/normal.c:466:3
= 30 0xe4295c in main /home/travis/build/neovim/neovim/src/nvim/main.c:572:3
= 31 0x2b2ba340bf44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
= 32 0x44d24b in _start (/home/travis/build/neovim/neovim/build/bin/nvim+0x44d24b)
=
= 0x611000000cd0 is located 16 bytes inside of 240-byte region [0x611000000cc0,0x611000000db0)
= freed by thread T1 here:
= 0 0x4ee0e2 in __interceptor_free /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:47:3
= 1 0xf4f6d4 in xfree /home/travis/build/neovim/neovim/src/nvim/memory.c:133:3
= 2 0x182a963 in tui_main /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:383:3
= 3 0x18792b0 in ui_thread_run /home/travis/build/neovim/neovim/src/nvim/ui_bridge.c:106:3
= 4 0x2b2ba2697183 in start_thread /build/eglibc-ripdx6/eglibc-2.19/nptl/pthread_create.c:312
=
= previously allocated by thread T0 here:
= 0 0x4ee61a in calloc /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:76:3
= 1 0xf4f787 in xcalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:147:15
= 2 0x182000a in tui_start /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:127:12
= 3 0x1863f7c in ui_builtin_start /home/travis/build/neovim/neovim/src/nvim/ui.c:125:3
= 4 0xe41bb9 in main /home/travis/build/neovim/neovim/src/nvim/main.c:457:5
= 5 0x2b2ba340bf44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
=
= Thread T1 created by T0 here:
= 0 0x4d774d in __interceptor_pthread_create /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:317:3
= 1 0x1aae6b0 in uv_thread_create /home/travis/nvim-deps/build/src/libuv/src/unix/thread.c:75
= 2 0x18217fa in tui_start /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:159:10
= 3 0x1863f7c in ui_builtin_start /home/travis/build/neovim/neovim/src/nvim/ui.c:125:3
= 4 0xe41bb9 in main /home/travis/build/neovim/neovim/src/nvim/main.c:457:5
= 5 0x2b2ba340bf44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287
---
Alternative attempt:
commit 6ad9c02491606a0c31e907f38c9931f324327aa5
Author: Justin M. Keyes <justinkz@gmail.com>
Date: Sat Jan 27 15:12:58 2018 +0100
tui: fix use-after-free: swap in empty scheduler
This should make life easier for UIs like VimR which implement their own
in-process bridged UI: they don't need to worry that their `scheduler`
might receive an invalid pointer.
To avoid that, ui_bridge_stopped() swaps in an empty scheduler. Note
that this requires the call to loop_poll_events() to be moved into the
critical section.
diff --git a/src/nvim/ui_bridge.c b/src/nvim/ui_bridge.c
index 779585416f80..491052d19d3b 100644
--- a/src/nvim/ui_bridge.c
+++ b/src/nvim/ui_bridge.c
@@ -93,10 +93,18 @@ UI *ui_bridge_attach(UI *ui, ui_main_fn ui_main, event_scheduler scheduler)
return &rv->bridge;
}
+static void ui_bridge_null_scheduler(Event event, void *d)
+{
+ WLOG("ignoring event (bridge stopped)");
+}
+
void ui_bridge_stopped(UIBridgeData *bridge)
{
uv_mutex_lock(&bridge->mutex);
bridge->stopped = true;
+ // Replace with an empty scheduler, so that the UI internal scheduler does
+ // not get invoked with an invalid pointer. #7922
+ bridge->scheduler = ui_bridge_null_scheduler;
uv_mutex_unlock(&bridge->mutex);
}
@@ -111,14 +119,11 @@ static void ui_bridge_stop(UI *b)
UIBridgeData *bridge = (UIBridgeData *)b;
bool stopped = bridge->stopped = false;
UI_BRIDGE_CALL(b, stop, 1, b);
- for (;;) {
+ while (!stopped) {
uv_mutex_lock(&bridge->mutex);
stopped = bridge->stopped;
- uv_mutex_unlock(&bridge->mutex);
- if (stopped) {
- break;
- }
loop_poll_events(&main_loop, 10); // Process one event (at most).
+ uv_mutex_unlock(&bridge->mutex);
}
uv_thread_join(&bridge->ui_thread);
uv_mutex_destroy(&bridge->mutex);
We were initially checking whether to apply 'langmap' translation based
on typebuf.tb_maplen.
This gets set to 0 on the last byte of a map when the del_typebuf()
function is called, which means that the option was not working for the
last character of a mapping.
For this reason, we switched to using KeyTyped to decide whether to
apply the transformation or not in commit 53da57d27.
Substituting one for the other isn't enough, because KeyTyped isn't set
until vgetorpeek() is returning.
This means 'langmap' translations are not applied when searching for
characters to map in the vgetorpeek() function if the *previous* key was
not typed.
We can't assert that both hold, as we would then *not* apply the
transformation when looking for a map starting with the first typed key
after a previously expanded map (as KeyTyped would be `false` from the
previously expanded map, and not yet reset).
Hence we assert that if we are looking for the mapping while in
vgetorpeek(), the map length should be zero, otherwise, KeyTyped must be
`true`.
This is implemented by checking for the variable `vgetc_busy`.
Problem: CTRL-G/CTRL-T don't work with incsearch and empty pattern.
Solution: Use the last search pattern. (Christian Brabandt, closesvim/vim#2292)
d048009717
Problem: 'hlsearch' highlighting not removed after incsearch (lacygoill)
Solution: Redraw all windows. Start search at the end of the match. Improve
how CTRL-G works with incremental search. Add tests. (Christian
Brabandt, Hirohito Higashi, haya14busa, closesvim/vim#2267)
f8f8b2eadb
Problem: Incremental search only shows one match.
Solution: When 'incsearch' and and 'hlsearch' are both set highlight all
matches. (haya14busa, closesvim/vim#2198)
2e51d9a097
vim-patch:8.0.0431: 'cinoptions' cannot set indent for extern block
Problem: 'cinoptions' cannot set indent for extern block.
Solution: Add the "E" flag in 'cinoptions'. (Hirohito Higashi)
7720ba8599
When tv_get_string_chk returns a non-NULL value, we have a valid string.
Propagating an error state (*len = -1, NULL return) for an empty string
is invalid.
Closes#6554
On macOS $TMPDIR defaults to something very long. There's not really
a need to support overriding the $TMPDIR used by tests, so always use
the workspace-local path "Xtest-tmpdir".
Prior to CMake 2.8.12, generator expressions could only be used in
custom commands so the path to libnvim-test in test/config/paths.lua was
set by inspecting the target's LOCATION property. Post 2.8.12, the
file(GENERATE) command exists to handle this, but it can't interpolate
normal CMake variables.
In order to bridge the gap while < 2.8.12 is supported, use
configure_file() to create paths.lua.gen with the
$<TARGET_FILE:nvim-test> generator expression and then generate the
final paths.lua file.
Closes#7077
The argument expansion for :Man depends on the number of arguments given to it
starting at the command itself. But user completion functions always provide the
entire command-line which can include modifier commands like :tab, :vert, etc.
leading to a wrong number of arguments.
Prune all arguments up to :Man.
Fixes#7872.
For some reason, using the clang executable inside of the Xcode default
toolchain the platform's sysroot include isn't present. This was
debugged by adding "-###" on the command line for generating the header
for nvim/os/lang.c and is was evident the flag was missing.
vim-patch:8.0.0674: cannot build with eval but without timers
vim-patch:8.0.0673: build failure without conceal feature
vim-patch:8.0.0668: nsis installer script does not work
vim-patch:8.0.0666: dead for loop
vim-patch:8.0.0665: warning for uninitialized variable
vim-patch:8.0.0664: mouse does not work in tmux
vim-patch:8.0.0661: recognizing urxvt mouse codes does not work well
vim-patch:8.0.0660: silent install on MS-Windows shows dialog
[Only the test is merged; code was addressed by 60c025267265.]
Problem: Memory access error when command follows :endfunction. (Nikolai
Pavlov)
Solution: Make memory handling in :function straightforward. (closesvim/vim#1793)
53564f7c1a
[Test passes, and the code change doesn't look applicable. So this only
includes the test.]
Problem: Cannot use ! after some user commands.
Solution: Properly check for existing command. (Higashi Higashi)
6f9a476b2f
Problem: Text found after :endfunction is silently ignored.
Solution: Give a warning if 'verbose' is set. When | or \n are used,
execute the text as a command.
663bb23316
Note: the code part of this patch was addressed by 60c0252672.
Problem: Patch shell command uses double quotes around the argument, which
allows for $HOME to be expanded. (Etienne)
Solution: Use single quotes on Unix. (closesvim/vim#1543)
1ef73e33c9
Problem: diff mode is insufficiently tested
Solution: Add more test cases. (Dominique Pelle, closesvim/vim#1685)
79a213d6a4
NA / already applied:
---------------------
vim-patch:8.0.0421: diff mode wrong when adding line at end of buffer
Problem: Diff mode is displayed wrong when adding a line at the end of a
buffer.
Solution: Adjust marks in diff mode. (James McCoy, closesvim/vim#1329)
f58a8475e1
Problem: No tests for ":set completion" and various errors of the :set
command.
Solution: Add more :set tests. (Dominique Pelle, closesvim/vim#1440)
698f8b207b
---
Also move test_options from test_alot to Makefile. (That's done upstream
in Vim patch 8.0.0430.)
ASAN log:
==23244==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 3348 byte(s) in 228 object(s) allocated from:
0 0x4ee3d3 in malloc /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67:3
1 0xf4e681 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:87:15
2 0xf4e8a9 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:121:15
3 0xf4ee68 in xmallocz /home/travis/build/neovim/neovim/src/nvim/memory.c:196:15
4 0x170e3ee in vim_strnsave /home/travis/build/neovim/neovim/src/nvim/strings.c:70:28
5 0x73b2ff in ex_loadkeymap /home/travis/build/neovim/neovim/src/nvim/digraph.c:1814:16
6 0xb1ef4c in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2242:5
7 0xb011b3 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:609:20
8 0xaee67d in do_source /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2970:3
9 0xae82ae in source_callback /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2326:9
10 0xae7adf in do_in_path /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2404:15
11 0xae7f48 in do_in_path_and_pp /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2448:12
12 0xae8281 in source_in_path /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2496:10
13 0xae610c in source_runtime /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2490:10
14 0x739887 in keymap_init /home/travis/build/neovim/neovim/src/nvim/digraph.c:1755:9
15 0x11d423e in did_set_string_option /home/travis/build/neovim/neovim/src/nvim/option.c:2678:16
16 0x11eecc4 in set_string_option /home/travis/build/neovim/neovim/src/nvim/option.c:2409:27
17 0x119852f in set_option_value /home/travis/build/neovim/neovim/src/nvim/option.c:4849:14
18 0x11bccac in set_bool_option /home/travis/build/neovim/neovim/src/nvim/option.c:3984:7
19 0x11a9d50 in do_set /home/travis/build/neovim/neovim/src/nvim/option.c:1424:30
20 0xb8caf7 in ex_set /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:9764:9
21 0xb1ef4c in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2242:5
22 0xb011b3 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:609:20
23 0x818b42 in call_user_func /home/travis/build/neovim/neovim/src/nvim/eval.c:21315:3
24 0x7e41bb in call_func /home/travis/build/neovim/neovim/src/nvim/eval.c:6358:11
25 0x7f8fb8 in get_func_tv /home/travis/build/neovim/neovim/src/nvim/eval.c:6120:11
26 0x7f1ba1 in ex_call /home/travis/build/neovim/neovim/src/nvim/eval.c:2735:9
27 0xb1ef4c in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2242:5
28 0xb011b3 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:609:20
29 0x837ef1 in ex_execute /home/travis/build/neovim/neovim/src/nvim/eval.c:19463:7
Direct leak of 456 byte(s) in 228 object(s) allocated from:
0 0x4ee3d3 in malloc /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:67:3
1 0xf4e681 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:87:15
2 0xf4e8a9 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:121:15
3 0xf4ee68 in xmallocz /home/travis/build/neovim/neovim/src/nvim/memory.c:196:15
4 0x170e3ee in vim_strnsave /home/travis/build/neovim/neovim/src/nvim/strings.c:70:28
5 0x73b18f in ex_loadkeymap /home/travis/build/neovim/neovim/src/nvim/digraph.c:1811:18
6 0xb1ef4c in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2242:5
7 0xb011b3 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:609:20
8 0xaee67d in do_source /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2970:3
9 0xae82ae in source_callback /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2326:9
10 0xae7adf in do_in_path /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2404:15
11 0xae7f48 in do_in_path_and_pp /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2448:12
12 0xae8281 in source_in_path /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2496:10
13 0xae610c in source_runtime /home/travis/build/neovim/neovim/src/nvim/ex_cmds2.c:2490:10
14 0x739887 in keymap_init /home/travis/build/neovim/neovim/src/nvim/digraph.c:1755:9
15 0x11d423e in did_set_string_option /home/travis/build/neovim/neovim/src/nvim/option.c:2678:16
16 0x11eecc4 in set_string_option /home/travis/build/neovim/neovim/src/nvim/option.c:2409:27
17 0x119852f in set_option_value /home/travis/build/neovim/neovim/src/nvim/option.c:4849:14
18 0x11bccac in set_bool_option /home/travis/build/neovim/neovim/src/nvim/option.c:3984:7
19 0x11a9d50 in do_set /home/travis/build/neovim/neovim/src/nvim/option.c:1424:30
20 0xb8caf7 in ex_set /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:9764:9
21 0xb1ef4c in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2242:5
22 0xb011b3 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:609:20
23 0x818b42 in call_user_func /home/travis/build/neovim/neovim/src/nvim/eval.c:21315:3
24 0x7e41bb in call_func /home/travis/build/neovim/neovim/src/nvim/eval.c:6358:11
25 0x7f8fb8 in get_func_tv /home/travis/build/neovim/neovim/src/nvim/eval.c:6120:11
26 0x7f1ba1 in ex_call /home/travis/build/neovim/neovim/src/nvim/eval.c:2735:9
27 0xb1ef4c in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2242:5
28 0xb011b3 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:609:20
29 0x837ef1 in ex_execute /home/travis/build/neovim/neovim/src/nvim/eval.c:19463:7
SUMMARY: AddressSanitizer: 3804 byte(s) leaked in 456 allocation(s).
Failed: E /tests/oldtests|logs :: Runtime errors detected.
Problem: The effect of adding "vim/vim#" to 'cinoptions' is not always removed.
(David Briscoe)
Solution: Reset b_ind_hash_comment. (Christian Brabandt, closesvim/vim#1475)
6b64394f34
This should handle most cases where Nvim was invoked as $MANPAGER.
Ultimately the stakes are low: :quit will prompt if there are unsaved
changes.
fix#7873
cb02137dfa had two mistakes, of the same nature: trans_special() must
be invoked with in_string=false unless the parsing context is a VimL
string. replace_termcodes() and input_enqueue() are low-level
mechanisms where VimL strings do not exist.
keymap.c: adjust double-quote case to satisfy keymap_spec.lua
closes#7410
closes#7572closes#7579closes#7628
ASAN report:
==9500==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000024c0 at pc 0x00000187d2ca bp 0x7fc3c6e58d10 sp 0x7fc3c6e58d08
READ of size 8 at 0x6040000024c0 thread T1
0 0x187d2c9 in ugrid_put /home/vagrant/neovim/build/../src/nvim/ugrid.c:107:17
1 0x1850adf in tui_put /home/vagrant/neovim/build/../src/nvim/tui/tui.c:1012:10
2 0x18a6ce6 in ui_bridge_put_event /home/vagrant/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:154:3
3 0xa4dcda in multiqueue_process_events /home/vagrant/neovim/build/../src/nvim/event/multiqueue.c:150:7
4 0xa478bf in loop_poll_events /home/vagrant/neovim/build/../src/nvim/event/loop.c:63:3
5 0x185451c in tui_main /home/vagrant/neovim/build/../src/nvim/tui/tui.c:362:12
6 0x18a3080 in ui_thread_run /home/vagrant/neovim/build/../src/nvim/ui_bridge.c:106:3
7 0x7fc3caaac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
8 0x7fc3c9ca33dc in clone /build/glibc-bfm8X4/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109
0x6040000024c0 is located 0 bytes to the right of 48-byte region [0x604000002490,0x6040000024c0)
allocated by thread T1 here:
0 0x50e048 in malloc (/home/vagrant/neovim/build/bin/nvim+0x50e048)
1 0xf7ab71 in try_malloc /home/vagrant/neovim/build/../src/nvim/memory.c:87:15
2 0xf7ad99 in xmalloc /home/vagrant/neovim/build/../src/nvim/memory.c:121:15
3 0x187937b in ugrid_resize /home/vagrant/neovim/build/../src/nvim/ugrid.c:32:17
4 0x184be58 in tui_resize /home/vagrant/neovim/build/../src/nvim/tui/tui.c:770:3
5 0x18a3dc8 in ui_bridge_resize_event /home/vagrant/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:4:3
6 0xa4dcda in multiqueue_process_events /home/vagrant/neovim/build/../src/nvim/event/multiqueue.c:150:7
7 0xa478bf in loop_poll_events /home/vagrant/neovim/build/../src/nvim/event/loop.c:63:3
8 0x185451c in tui_main /home/vagrant/neovim/build/../src/nvim/tui/tui.c:362:12
9 0x18a3080 in ui_thread_run /home/vagrant/neovim/build/../src/nvim/ui_bridge.c:106:3
10 0x7fc3caaac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
Thread T1 created by T0 here:
0 0x4655ed in __interceptor_pthread_create (/home/vagrant/neovim/build/bin/nvim+0x4655ed)
1 0x1ad87b0 in uv_thread_create /home/vagrant/neovim/.deps/build/src/libuv/src/unix/thread.c:75
2 0x184b9aa in tui_start /home/vagrant/neovim/build/../src/nvim/tui/tui.c:159:10
3 0x188dd4c in ui_builtin_start /home/vagrant/neovim/build/../src/nvim/ui.c:125:3
4 0xe6d399 in main /home/vagrant/neovim/build/../src/nvim/main.c:457:5
5 0x7fc3c9bbc82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
Problem: Invalid memory access when using :sc in Ex mode. (Dominique Pelle)
Solution: Avoid the column being negative. Also fix a hang in Ex mode.
ba748c8a84
vim-patch:8.0.0151
Problem: To pass buffer content to system() and systemlist() one has to
first create a string or list.
Solution: Allow passing a buffer number. (LemonBoy,
closesvim/vim#1240)
12c4492dd3
vim-patch:8.0.0153
Problem: system() test fails on MS-Windows.
Solution: Deal when extra space and CR.
9d9c356517
vim-patch:8.0.0154
Problem: system() test fails on OS/X.
Solution: Deal with leading spaces.
31f19ce0a0
Error detected while processing function man#open_page[58]..<SNR>54_put_page:
line 8:
E5105: Error while calling lua chunk: /usr/share/nvim/runtime/lua/man.lua:165: Vim(let):E805: Using a Float as a Number
Problem: Diff mode is displayed wrong when adding a line at the end of a
buffer.
Solution: Adjust marks in diff mode. (James McCoy, closesvim/vim#1329)
f58a8475e1
Problem: Test for arabic does not check what is displayed.
Solution: Improve what is asserted. (Dominique Pelle, closesvim/vim#1523)
Add a first shaping test.
5342f00ff9
Problem: With 'linebreak' set and 'breakat' includes ">" a double-wide
character results in "<<" displayed.
Solution: Check for the character not to be replaced. (Ozaki Kiichi,
closesvim/vim#1456)
38632faf63
New logging is guarded by cmake LOG_LIST_ACTIONS define. To make it more
efficient it is allocated as a linked list with chunks of length
2^(7+chunk_num); that uses basically the same idea as behind increasing kvec
length (make appending O(1) (amortized)), but reduces constant by not bothering
to move memory around what realloc() would surely do: it is not like we need
random access to log entries here to justify usage of a single continuous memory
block.
Problem: Illegal memory access with z= command. (Dominique Pelle)
Solution: Avoid case folded text to be longer than the original text. Use
MB_PTR2LEN() instead of MB_BYTE2LEN().
5b276aa80e
vim-patch:8.0.0364: ]s does not move cursor with two spell errors in one line
Problem: ]s does not move cursor with two spell errors in one line. (Manuel
Ortega)
Solution: Don't stop search immediately when wrapped, search the line first.
(Ken Takata) Add a test.
d3f78dc9eb
* disable spell test for now
Implement nvim_command_output with `execute({cmd},"silent")`.
Behavior changes:
- does not provoke any hit-enter prompt
- no longer prepends a newline char
- does not capture some noise (like the "[New File]" message, see the
change to tabnewentered_spec.lua)
Technically ("bug-for-bug") this a breaking change. But the previous
behavior of nvim_command_output meant that it probably wasn't used for
anything outside of tests.
Also remove the undocumented `v:command_output` variable which was
a hack introduced only for the purposes of nvim_command_output.
closes#7726
Workaround for this fun new issue:
==27404==LeakSanitizer has encountered a fatal error.
==27404==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==27404==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
Failed: E /build|logs :: Runtime errors detected.
https://github.com/travis-ci/travis-ci/issues/9033https://github.com/google/sanitizers/issues/764
Problem: When completing a group name for a highlight or syntax command
cleared groups are included.
Solution: Skip groups that have been cleared.
d61e8aaae5
Problem: Some syntax arguments take effect even after "if 0". (Taylor
Venable)
Solution: Properly skip the syntax statements. Make "syn case" and "syn
conceal" report the current state. Fix that "syn clear" didn't
reset the conceal flag. Add tests for :syntax skipping properly.
de318c5c35
Problem: The condition for when a typval needs to be cleared is too
complicated.
Solution: Init the type to VAR_UNKNOWN and clear it always.
f06e5a549f
With 6fa0a0a516 the neovim-ruby gem installs successfully, but
ruby_spec.lua can't find it: g:ruby_host_prog needs to be set correctly.
Just skip the whole thing for now, so that CI builds don't fail.
Until now, the default `:filetype ...` setup was skipped if the user
config touched `:filetype` in any way (including implicitly via `:syntax
on`). No one needs that, and it's very confusing.
Instead, proceed with `:filetype ... on` unless the user explicitly
called `:filetype ... off`.
closes#7765
Problem: Test_existent_file() fails on some file systems.
Solution: Run the test again with a sleep when the test fails without a
sleep. (James McCoy, closesvim/vim#1984)
82de3c2c03
do_profiling is a global variable, and as such the clang static
analyzer has trouble making arguments about it.
This commit does one comparison against do_profiling and puts the
result in a local variable. This prevents errors from the value of
do_profiling changing between comparisons.
The clang static analyzer convinced itself lp->ll_newkey could be NULL.
This adds an assertion that checks this doesn't actually happen, as well
as a parallel assertion for di->di_key.
Clang static analyzer had trouble with filter_map in eval.c because
tv_copy could, in principle, change the v_type of argvars[0]. It
saw a potential null pointer going somewhere it shouldn't as a result.
The from argument in tv_copy should be const, which also cleans up the
static analyzer's complaint.
Separating the non-flaky builds (asan, normal builds, lint) into
separate stages simply slowed down overall CI turnaround. Since none of
the builds rely on the output of others, reducing the stages increases
the opportunities for parallel builds.
The llvm repos commonly have access issues, so removing them will
improve stability of the Travis builds.
Filtering check_log's output through asan_symbolize also avoids the
version dance every time a new clang version makes its way into Travis.
TERM=konsole-256color is recognized by ncurses.
TERM=konsole-xterm might be more clever, but should not be necessary
(for Nvim at least), we already special-case Konsole in various places.
We may need to clean up some areas that currently assume Konsole always
"pretends xterm" (`TERM=xterm-256color`), though I didn't find any such
cases.
ref #6403
ref https://github.com/neovim/neovim/issues/6403#issuecomment-348713346
Problem: Flags of :substitute not sufficiently tested.
Solution: Test up to two letter flag combinations. (James McCoy, closes
vim/vim#1479)
8c50d50b6e
vim-patch:8.0.0334
vim-patch:8.0.0335
vim-patch:8.0.0343
vim-patch:8.0.0345
Problem: Can't access b:changedtick from a dict reference.
Solution: Make changedtick a member of the b: dict. (inspired by neovim
vim/vim#6112)
79518e2ace
vim-patch:8.0.0343: b:changedtick can be unlocked
Problem: b:changedtick can be unlocked, even though it has no effect.
(Nikolai Pavlov)
Solution: Add a check and error E940. (closes#1496)
vim-patch:8.0.0345: islocked('d.changedtick') does not work
Problem: islocked('d.changedtick') does not work.
Solution: Make it work.
vim-patch:8.0.0335: functions test fails
Problem: Functions test fails.
Solution: Use the right buffer number.
507647da31
Problem: Cannot set a separate highlighting for the current line in the
quickfix window.
Solution: Add QuickFixLine. (anishsane, closesvim/vim#1755)
2102035488
Problem: Cannot easily get to the last quickfix list.
Solution: Add "$" as a value for the "nr" argument of getqflist() and
setqflist(). (Yegappan Lakshmanan)
875feea6ce
For back-compat, :CheckHealth runs :checkhealth. But don't define
:CheckHealth explicitly, it adds noise to wildmenu completion.
Completion of healthchecks doesn't yet work with :checkhealth, this is
a regression but it needs to be implemented for :checkhealth rather than
keeping :CheckHealth around.
vim-patch:8.0.1206: no autocmd for entering or leaving the command line
(commit a4f6cec7a3)
NA patches:
vim-patch:8.0.0320: warning for unused variable with small build
Reason: test may contain cleanup at the endwhich is needed for GC to work
properly, but is not done if test fails. With collectgarbage() in former
position it would crash when collecting garbage.
Problem: Cannot set the context for a specified quickfix list.
Solution: Use the list index instead of the current list. (Yegappan
Lakshmanan)
6e62da3e14
Problem: Cannot add a context to locations.
Solution: Add the "context" entry in location entries. (Yegappan Lakshmanan,
closesvim/vim#1012)
8f77c5a4ec
Problem: There is no way to remove quickfix lists (for testing).
Solution: Add the 'f' action to setqflist(). Add tests. (Yegappan
Lakshmanan)
b6fa30ccc3
Problem: Using :lhelpgrep with an argument that should fail does not
produce an error if the previous :helpgrep worked.
Solution: Use another way to detect that autocommands made the quickfix info
invalid. (Yegappan Lakshmanan)
ee85df3763
clang ASAN/LeakSanitizer error (observed in #7706):
==21832==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 56 byte(s) in 1 object(s) allocated from:
0 0x511b26 in malloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x511b26)
1 0x1009a84 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:87:15
2 0x1009c44 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:121:15
3 0xaa8c36 in loop_schedule_deferred /home/travis/build/neovim/neovim/src/nvim/event/loop.c:89:19
4 0x190856a in tui_main /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:367:5
5 0x1963d61 in ui_thread_run /home/travis/build/neovim/neovim/src/nvim/ui_bridge.c:106:3
6 0x2b5d4190d183 in start_thread /build/eglibc-SvCtMH/eglibc-2.19/nptl/pthread_create.c:312
Possible explanation: During exit, `Loop.thread_events` may not get
flushed, so `loop_deferred_event()` is never called.
We could instead try to unwind `Loop.thread_events` during teardown, but
it seems lower-risk to just tell ASAN to ignore it.
Valgrind does not complain:
$ while :; do { 2>valglog.txt valgrind ./build/bin/nvim -u NONE +q ; } ; if ! [ $? = 0 ] ; then break ; fi ; done
Problem: When running :make the output may be in the system encoding,
different from 'encoding'.
Solution: Add the 'makeencoding' option. (Ken Takata)
2c7292dc5b
provider#node#can_inspect will fail on some systems because it is common
to have old node versions in OS (any Linux OS that has LTS releases)
and CI (Travis, Appveyor).
NODE_PATH can be trivially set with VimL.
Build scripts don't have to set it for the nodejs tests to work.
NODE_PATH is optional to begin with and is used only as a workaround
for the neovim node.js host.
ci: install nodejs 8 in Appveyor, Travis
provider: check node version for debug support
Resolve https://github.com/neovim/neovim/pull/7577#issuecomment-350590592 for Unix.
provider: test if nodejs in ci supports --inspect-brk
nodejs host for neovim requires nodejs 6+ to work properly.
nodejs 6.12+ or 7.6+ is required for debug support via `node --inspect-brk`.
provider: run cli.js of nodejs host directly
npm shims are useless because the user cannot set node to debug mode via
--inspect-brk. This is problematic on Windows which use batchfiles and
shell scripts to compensate for not supporting shebang.
The patch uses `npm root -g` to get the absolute path of the global npm
modules. If that fails, then the user did not install neovim npm package
globally. Use that absolute path to find `neovim/bin/cli.js`, which is
what the npm shim actually runs with node. glob() is for a simple file
check in case bin/ is removed because the npm shims are ignored now.
- Revert timer-based approach.
- Instead, call loop_poll_events() with a timeout in an "active" loop,
to infer that "TUI startup activity has mostly finished", but also to
enforce a mininum time (100 ms) before emitting "enable focus
reporting" termcode. (If TUI startup takes longer than that minimum
time, it's probably a slow environment anyways.)
- Tickle `main_loop` by sending a dummy event. Without this, the
initial "focus-gained" response from the terminal may not get
processed until the user hits a key.
ref #7720
ref #7664
ref #7649
ref #7664
ref 27f9b1c7b0
Problem: Cannot make Vim fail on an internal error.
Solution: Add IEMSG() and IEMSG2(). (Domenique Pelle) Avoid reporting an
internal error without mentioning where.
95f096030e
Signed-off-by: Michael Schupikov <michael@schupikov.de>
* typval_encode.c.h: avoid -Wnonnull-compare warning
closes#6847
The NULL check is needed because TYPVAL_ENCODE_CONV_EMPTY_DICT may be
invoked with literal `NULL`.
Warning occurs even for `Debug` build-type:
neovim/src/nvim/eval/typval.c: In function ‘_typval_encode_nothing_convert_one_value’:
neovim/src/nvim/eval/typval.c:1802:10: warning: nonnull argument ‘tv’ compared to NULL [-Wnonnull-compare]
if (tv != NULL) { \
^
../src/nvim/eval/typval_encode.c.h:398:9: note: in expansion of macro ‘TYPVAL_ENCODE_CONV_EMPTY_DICT’
TYPVAL_ENCODE_CONV_EMPTY_DICT(tv, tv->vval.v_dict);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gcc version:
gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
* fixup! typval_encode.c.h: avoid -Wnonnull-compare warning
With this implementation there is no "jank" during startup.
Using the main_loop in any fashion is janky. Using only the TUI loop
emits the termcodes too soon, or requires bad hacks like counting
tui_flush invocations (9 seems to work).
ref #7664
ref #7649
ref #7664
ref 27f9b1c7b0
vim-patch:8.0.0299 NA
vim-patch:8.0.0309 NA
vim-patch:8.0.0310 NA
vim-patch:8.0.0215 NA
Problem: When a Cscope line contains CTRL-L a NULL pointer may be used.
(Coverity)
Solution: Don't check for an emacs tag in a cscope line.
e362c3d2c3
vim-patch:8.0.0244 NA
Problem: When the user sets t_BE empty after startup to disable bracketed
paste, this has no direct effect.
Solution: When t_BE is made empty write t_BD. When t_BE is made non-empty
write the new value.
d9c60648e5
Some patches were not properly marked in the commit logs. So they are
marked here:
vim-patch:8.0.1230
vim-patch:8.0.1229
vim-patch:8.0.0618
vim-patch:8.0.0104
vim-patch:8.0.0405
vim-patch:8.0.0400
vim-patch:8.0.0302
vim-patch:8.0.0288
vim-patch:8.0.0285
vim-patch:8.0.0284
vim-patch:8.0.0281
vim-patch:8.0.0279
vim-patch:8.0.0278
vim-patch:8.0.0277
vim-patch:8.0.0276
vim-patch:8.0.0273
vim-patch:8.0.0272
vim-patch:8.0.0271
vim-patch:8.0.0270
vim-patch:8.0.0269
vim-patch:8.0.0268
vim-patch:8.0.0267
vim-patch:8.0.0260
vim-patch:8.0.0257
vim-patch:8.0.0249
vim-patch:8.0.0248
vim-patch:8.0.0246
vim-patch:8.0.0244
vim-patch:8.0.0241
vim-patch:8.0.0240
vim-patch:8.0.0239
vim-patch:8.0.0232
vim-patch:8.0.0221
vim-patch:8.0.0217
vim-patch:8.0.0215
vim-patch:8.0.0213
vim-patch:8.0.0211
vim-patch:8.0.0203
vim-patch:8.0.0199
vim-patch:8.0.0193
vim-patch:8.0.0192
vim-patch:8.0.0191
vim-patch:8.0.0187
vim-patch:8.0.0183
vim-patch:8.0.0180
vim-patch:8.0.0173
vim-patch:8.0.0171
vim-patch:8.0.0170
vim-patch:8.0.0169
vim-patch:8.0.0166
vim-patch:8.0.0163
vim-patch:8.0.0162
vim-patch:8.0.0161
vim-patch:8.0.0152
vim-patch:8.0.0145
vim-patch:8.0.0144
vim-patch:8.0.0141
vim-patch:8.0.0139
vim-patch:8.0.0138
vim-patch:8.0.0130
vim-patch:8.0.0129
vim-patch:8.0.0123
vim-patch:8.0.0122
vim-patch:8.0.0120
vim-patch:8.0.0117
vim-patch:8.0.0115
vim-patch:8.0.0114
vim-patch:8.0.0113
vim-patch:8.0.0109
vim-patch:8.0.0108
vim-patch:8.0.0107
vim-patch:8.0.0105
vim-patch:8.0.0103
vim-patch:8.0.0098
vim-patch:8.0.0097
vim-patch:8.0.0095
vim-patch:8.0.0094
vim-patch:8.0.0093
vim-patch:8.0.0089
vim-patch:8.0.0087
vim-patch:8.0.0082
vim-patch:8.0.0080
vim-patch:8.0.0077
vim-patch:8.0.0076
vim-patch:8.0.0072
vim-patch:8.0.0071
vim-patch:8.0.0070
vim-patch:8.0.0067
vim-patch:8.0.0065
vim-patch:8.0.0063
vim-patch:8.0.0061
vim-patch:8.0.0059
vim-patch:8.0.0055
vim-patch:8.0.0054
vim-patch:8.0.0051
vim-patch:8.0.0050
vim-patch:8.0.0048
vim-patch:8.0.0045
vim-patch:8.0.0039
vim-patch:8.0.0036
vim-patch:8.0.0030
vim-patch:8.0.0029
vim-patch:8.0.0028
vim-patch:8.0.0027
vim-patch:8.0.0024
vim-patch:8.0.0022
vim-patch:8.0.0021
vim-patch:8.0.0018
vim-patch:8.0.0016
vim-patch:8.0.0015
vim-patch:8.0.0014
vim-patch:8.0.0013
vim-patch:8.0.0011
vim-patch:8.0.0010
vim-patch:8.0.0009
vim-patch:8.0.0007
vim-patch:8.0.0005
Use `@cond <something>` to obscure a section from doxygen.
doxygen thinks kvec_withinit_t() is a function. That adds noise to the
generated API documentation, and also prevents the following function
from being noticed.
closes#7429
Problem: after a help window was closed, a window was selected and its
autocommands triggered. After that, restore_snapshot was called and the
focused window changed, confusing the user.
Solution: Add function get_snapshot_focus() that returns the window that
holds the cursor in a snapshot. Use this function in win_close to make
sure the right window is selected before any autocommand is triggered.
Unix's typical locale-related environment variables aren't always set
appropriately on a Mac. Instead of relying on them, query the locale
information using Mac specific APIs and then set $LANG appropriately for
the rest of nvim.
Closes#5873
The previous commit ensures that we can never flush the buffer in a
state where toggling cursor visibility can corrupt other escape codes.
Thus, we can remove the workaround added as part of e838452, simplyfing
the code and hiding the cursor on more occasions.
e83845285 fixed an issue where long (true color) escape sequences got
interrupted by the cursor visibility toggling caused by buffer flushes.
cdfaecb25 introduces a new issue which causes similar problems: While
the old buffer flushing code appended the cursor visibility escapes to
the buffer before/after flushing, the new code effectively prepends the
sequences.
Assume the following sequence of events occurs:
- A long escape code is issued using unibi_out when the buffer is
almost full
- out() gets called for a prefix of that escape code, causing the
buffer to fill up
- flush_buf(ui, false) is called and (correctly) does not insert any
cursor toggling escapes
- The rest of the escape code is written into the now empty buffer
- At some later point, some other part of nvim calls flush_buf(ui,
true), which then toggles the cursor, corrupting the escape code
This could possibly also be fixed by tracking the state of the buffer
(i.e. does it contain a partially output escape code?), but this seems
fragile in the same way e83845285 turned out to be.
The root cause for all these problems is the mismatch between nvim's
(implicit) assumption that the buffer is flushable at any point in time
and the non-atomicity of unibilium's character based callback interface.
The proper fix (without modifying unibilium) is to ensure nvim's
assumption about the buffer state holds at all times.
To that end, add a "cork" flag which ensures one unibi_out-call never
splits its output across a buffer flush; if an escape code does not fit
into the current buffer, flush it without any part of the escape code in
it and insert the whole escape code in the emptied buffer. This is a
little more complex because it modifies the buffer in place rather than
printing into another buffer, checking the remaining space in the
terminal buffer and then memcpy'ing it.
Get terminal debugging info by starting Nvim with 'verbose' level 3:
nvim -V3log
This is like Vim's `:set termcap`, which was removed in Nvim (and would
be very awkward to restore because of the decoupled UI).
filter('v:_null_list, 'v:val') should return v:_null_list and a similar
statement should hold for map.
Changes after review
* Test inserted in legacy test suite has been removed by reverting the commit
adding it.
* Change the fix to tv_copy the argument before returning.
* Readd the two tests on crashes, and modified their expected return value.
* Move the test from 'incorrect behaviour' section to 'correct behaviour section'
* Add analogous tests for v:_null_dict
Always copy list or dictionary to return variable
If the type of input is correct (i.e. either a list or a dictionary), this
should also be returned.
ref #7649
ref #766427f9b1c7b0 caused a regression: it uses loop_schedule_deferred() to
defer emitting the "enable focus reporting" termcode. tui_main() never
processes `tui_loop.events` (which loop_schedule_deferred() depends on),
so the event was never actually processed.
But fixing that (by processing `tui_loop.events`) would bring back the
problem 27f9b1c7b0 tried to fix: it still emits the event too soon.
Instead, do a little dance: schedule the event on `main_loop` and then
forward it to `tui_loop`.
NOTE: after this commit, in tmux 2.3 with `focus-events` enabled,
FocusGained is fired on startup and when resuming from suspend.
Using `script` to record the terminal session (and `vterm-dump` to
post-process the result):
BEFORE:
{DECSM 1049}{DECSM 1}{ESC =}
{CUP *}{ED *}{DECSM 2004}{DECSM 1004}{CSI 1,43 r}
{CUP 1,1}
{CUP *}{ED *}{SM 34}{DECSM 25}
{DECRM 25}{CSI 2 q}{CSI 2 q}
{CUP *}{ED *}{LF}
{SGR *}{LS1}{SGR 94}~
...
AFTER:
{CUP *}{ED *}{CSI 1,43 r}
{CUP 1,1}
{CUP *}{ED *}{SM 34}{DECSM 25}
{DECRM 25}{CSI 2 q}{CSI 2 q}
{CUP *}{ED *}{DECSM 2004}{DECSM 1004}{LF}
{SGR *}{LS1}{SGR 94}~
...
Note: there are three changes to ascii_isident. Reverting first two (in
find_special_key and first in get_special_key_code) normally fails the new test
with empty &isident, but reverting the third does not. Hence adding `>` to
&isident.
Ref vim/vim#2389.
When building with certain GCC versions, a _Float128 type is present
when setting up the ffi for unit tests.
./test/unit/helpers.lua:256: declaration specifier expected near '_Float128' at line 396
/usr/bin/luajit: /usr/share/lua/5.1/busted/runner.lua:99: attempt to concatenate local 'message' (a table value)
stack traceback:
/usr/share/lua/5.1/busted/runner.lua:99: in function 'fn'
/usr/share/lua/5.1/mediator.lua:103: in function 'publish'
/usr/share/lua/5.1/busted/modules/helper_loader.lua:21: in function 'helperLoader'
/usr/share/lua/5.1/busted/runner.lua:147: in function </usr/share/lua/5.1/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: at 0x004044a0
CMake Error at /<<PKGBUILDDIR>>/cmake/RunTests.cmake:53 (message):
Running unit tests failed with error: 1.
Since this is being pulled in by a dependency, not directly used by
nvim, just ignore the type.
Closes#7423
ruby uses batchfiles with 'cmd' extension.
gem creates batchfiles with 'bat' extension.
`gem install rails` does the following in Windows (not Cygwin):
1. Run `gem.cmd install rails` on cmd.exe
2. gem.cmd runs `ruby.exe -x gem install rails`
3. `rails` gem is installed.
`rails.bat` is created in the same directory
where ruby.exe and gem.cmd reside.
- channels: vim-patch:8.0.0018
- GUI: vim-patch:8.0.0021
- Different recursive function implementation: vim-patch:8.0.0141
- JSON handling: vim-patch:8.0.0166, vim-patch:8.0.0169, vim-patch:8.0.0170,
vim-patch:8.0.0171, vim-patch:8.0.0180
Mark vim-patch:8.0.0096 applied, since it was added in
860ecd7055.
[ci skip]
Since "builtin" terminfo definitions were implemented (7cbf52db1b),
the decisions made by tui.c and terminfo.c are more relevant. Exposing
that decision in the 'term' option helps with troubleshooting.
Also: remove code that allowed setting t_Co. `:set t_Co=…` has never
worked; the highlight_spec test asserting that nvim_set_option('t_Co')
_does_ work makes no sense, and should not have worked.
If an EOF is returned from `fgets`, `vim_fgets` might spin forever, as
it tries to consume the current line.
A `NULL` return value from `fgets` should break out of the function
(unless `errno` is `EINTR`), and then `feof` should be used to check for
the EOF condition on the stream.
The calls to `fgets` in `src/nvim/if_cscope.c` (and elsewhere) can show
communication errors to the user if a signal is delivered during its
system calls. For plugins that proxy subprocess output into cscope
requests, a `SIGCHLD` might *always* interfere with calls into `fgets`.
To see this in a debugger, put a breakpoint on `cs_reading_emsg` and
watch signals come in (with lldb, using `process handle --notify true
--pass true`). Next, run a subcommand from neovim that calls through
cscope when it returns. A tag picker plugin, like vim-picker and fzy,
with `cscopetag` and `cscopetagorder=0` set, reproduced this reliably.
The breakpoint will hit after a `SIGCHLD` is delivered, and `errno` will
be set to 4, `EINTR`.
The caller of `fgets` should retry when `NULL` is returned with `errno`
set to `EINTR`.
On startup, if running in a terminal, save the termios properties.
Use the saved termios for `:terminal` and `jobstart()` pty jobs.
This won't affect nvim spawned outside of a terminal.
questions:
- This affects `:terminal` and `jobstart({'pty'✌️true})`.
Should we be more conservative for `jobstart({'pty'✌️true})` (e.g.
pass NULL to forkpty() and let the OS defaults prevail)?
- Note: `iutf8` would not be set in that case.
vim-patch:fafcf0dd59fd
patch 8.0.1206: no autocmd for entering or leaving the command line
Problem: No autocmd for entering or leaving the command line.
Solution: Add CmdlineEnter and CmdlineLeave.
fafcf0dd59
The hardcoded URL breaks very often, this confuses people.
Instead, auto-detect if no URL is provided.
Also auto-detect if the script is invoked with no arguments.
When building in release mode, gcc generated a maybe-initialized
warning in get_syn_options. The warning is both right and wrong;
there is an execution path where the len variable is not
initialized in the code:
...
int len;
...
for (fidx = ARRAY_SIZE(flagtab); --fidx >= 0; ) {
p = flagtab[fidx].name;
int i;
for (i = 0, len = 0; p[i] != NUL; i += 2, ++len)
if (arg[len] != p[i] && arg[len] != p[i + 1])
break;
// <snip>
}
...
arg = skipwhite(arg + len);
...
The initial for loop will not execute if ARRAY_SIZE(flagtab) == 0,
and thus len will never be initialized. flagtab is a local-static
variable, initialized to a long array of structured data, so
ARRAY_SIZE(flagtab) can't be 0.
However, gcc doesn't recognize ARRAY_SIZE(flagtab) as a constant.
There are any number of reasons this could happen. In any case,
the message can be fixed with a len=0 before the first for loop.
In addition to the above warning, I've labeled flagtab and
first_letters as const. They should never change.
closes#7599
Helped-by: oni-link <knil.ino@gmail.com>
Freeing `dirname` was first introduced by a code refactoring from `ex_helptags()` to `do_helptags()` (`vim-patch:7.4.1551`)(#4648) and later removed by `vim-patch:7.4.1562`(#4660).
Only problem with that is, that the patches were not applied in order so the fixing patch was declared `N/A`.
So `do_helptags()` should have never freed `dirname`.
Problem: Cannot access the arguments of the current function in debug mode.
(Luc Hermitte)
Solution: use get_funccal(). (Lemonboy, closesvim/vim#1432, closesvim/vim#1352)
c7d9eacefa
When compiling with CMAKE_BUILD_TYPE=RelWithDebInfo, several
-Wmaybe-uninitialized warnings are printed. These were thought to
be false positives (#5061); there are no control paths that lead
to an uninitialized value. However, when gcc is run in -O2 mode,
it makes a mistake while generating the necessary logic.
Specifically, for the code:
...
int = 0; // Index of the server whose address equals addr.
for (; i < watchers.ga_len; i++) {
watcher = ((SocketWatcher **)watchers.ga_data)[i];
// <snip>
}
if (i >= watchers.ga_len) {
ELOG("Not listening on %s", addr);
return;
}
...
Gcc generates:
...
<+98>: cmp %ebx, %ebp
<+100>: jg 0x530f13 <server_stop+55>
<+102>: cmp %ebp, ebx
<+104>: jl 0x530f7e <server_stop+162>
...
Normally, the if statement should catch the only control path
where watcher is not assigned: watchers.ga_len <= 0. When
compiled, the assembly lines 98 and 100 correspond to checking if
i < watchers.ga_len, and the lines 102 and 104 correspond to
checking if i >= watchers.ga_len. The assembly seems to compare
ebp (which is watchers.ga_len) with ebx (which is i), and jump
if greater; then do the same comparison and jump if less. This is
where gcc makes a mistake: it flips the order of the cmp
instruction. This means that the REAL behavior is first check if
i < watchers.ga_len and then check if i < watchers.ga_len. Which
means the code inside the if statement is NEVER executed; no
combination of i and watchers.ga_len will ever trigger ELOG().
So not only is this a use of an uninitialized value if
watchers.ga_len == 0 (or technically, if it's less than zero too),
it also clobbers any error detection if the for loop reaches the
last entry (which would normally cause i == watchers.ga_len too).
This commit fixes this issue by adding a bool to keep track of
whether a watcher was found during the loop. This makes gcc
generate the correct code, avoiding both bugs.
Problem: The return value of mode() does not indicate that completion is
active in Replace and Insert mode. (Zhen-Huan (Kenny) Hu)
Solution: Add "c" or "x" for two kinds of completion. (Yegappan Lakshmanan,
closesvim/vim#1397) Test some more modes.
e90858d022
The flag enables the current local directory set by ":lcd" to be saved
to views which is the current default behaviour. The option can be
removed to disable this behaviour.
closes#7435
vim-patch:8.0.1289
neovim-ruby-host is a ruby script.
neovim-node-host is a shell script.
Both don't work in cmd.exe so gem and npm provide batchfile shims.
Return the full path of these shims, cmd.exe knows better what to do with these files.
Make the Windows impl closer to Vim os_win32.c, and the Unix impl closer
to Vim os_unix.c.
Outcomes:
- Do not send negative fd to close(). ref #4806#4772#6860
- Fallback return-value is now correct in (hopefully) all cases.
- unix: check S_ISXXX instead of relying on os_open (which can fail for
irrelevant reasons). buf_write() expects NODE_WRITABLE for character
devices such as /dev/stderr. 96f834a842
Anything claiming to be an xterm gets DECSCUSR. This is the only
reasonable choice unless/until we get more reliable detection (#7490).
ref #6997closes#7550
Fix bug that checked for npm AND yarn, where we wanted npm OR yarn.
But since we call `npm` exclusively, and it's highly unlikely you have
yarn installed without npm, let's just remove the yarn check altogether.
Addresses https://github.com/neovim/node-client/issues/41
Problem: Crash when 'fileformat' is forced to "dos" and the first line in
the file is empty and does not have a CR character.
Solution: Don't check for CR before the start of the buffer.
2aa5f696b9
:checkhealth reports that remote plugins are unregistered
after running :UpdateRemotePlugins because of the backslashes in filepath.
Normalize them to forward slashes because the paths in rplugin.vim are normalized in autoload/remote/host.vim.
* vim-patch:8.0.0245
Problem: The generated zh_CN.cp936.po message file is not encoded properly.
Solution: Instead of using zh_CN.po as input, use zh_CN.UTF-8.po.
16038d50c4
* vim-patch:8.0.0248
Problem: vim_strcat() cannot handle overlapping arguments.
Solution: Use mch_memmove() instead of strcpy(). (Justin M Keyes,
closesvim/vim#1415)
45600ce8f2
Integer is a 64-bit type so using %d can produce incorrect results.
test/functional/api/highlight_spec.lua @ 35: highlight api nvim_get_hl_by_id
...W7Xi/neovim-0.2.1/test/functional/api/highlight_spec.lua:46: Expected objects to be the same.
Passed in:
(string) 'Invalid highlight id: 7671724'
Expected:
(string) 'Invalid highlight id: 30000'
This fixes an apparent difference in behavior between Lua and LuaJIT.
Lua fails to format nil:
test/functional/terminal/tui_spec.lua:381: bad argument #2 to 'format' (string expected, got nil)
Doc for UV_PROCESS_DETACHED in uv.h mentions:
> child process will still keep the parent's event loop alive unless
> the parent process calls uv_unref() on the child's process handle.
ref #3944
This way code will be easier to adapt to handling (partially) non-expressions
like :let lvalue part or :function definitions, and that would be needed in the
future both for proper completion support and for the Ex commands parser.
Problem: When setting wildoptions=tagfile the completion context is not set
correctly. (desjardins)
Solution: Check for EXPAND_TAGS_LISTFILES. (Christian Brabandt, closesvim/vim#1399)
ba47b51ff8
Problem: Completion of user defined functions is not covered by tests.
Solution: Add tests. Also test various errors of user-defined commands.
(Dominique Pelle, closesvim/vim#1413)
65c836e600
Problem: No command line completion for :cexpr, :cgetexpr, :caddexpr, etc.
Solution: Make completion work. (Yegappan Lakshmanan) Add a test.
2b2207ba69
Problem: The test for patch 8.0.0224 misses the CR characters and passes
even without the fix. (Christian Brabandt)
Solution: Use double quotes and \<CR>.
1695f99d08
Problem: When 'fileformats' is changed in a BufReadPre auto command, it
does not take effect in readfile(). (Gary Johnson)
Solution: Check the value of 'fileformats' after executing auto commands.
(Christian Brabandt)
7a2699e868
Nvim note: intentionally did not include `--ttyfail` since its purpose
is not clear. (And it isn't used in any Vim test files/scripts).
---
Problem: When the input or output is not a tty Vim appears to hang.
Solution: Add the --ttyfail argument. Also add the "ttyin" and "ttyout"
features to be able to check in Vim script.
2cab0e1910
Fix quickfix performance optimization which prevented quickfix items
from being updated when there were multiple windows with location lists
but the buffer with errors only in one of the lists.
This way it works both after `nvim -u NORC` and after that and `colorscheme
wombat256mod`. Removed the comment because I do not actually know why it works
here with these arguments and not in previous position with previous arguments.
Note: formatc.lua was unable to swallow some newer additions to ExprASTNodeType
(specifically `kExprNodeOr = '|'` and probably something else), so all `= …`
were dropped: in any case they only were there in order to not bother updating
viml_pexpr_debug_print_ast_node and since it is now known all nodes which will
be present it is not much of an issue.
It also adds support for kExprLexOr which for some reason was forgotten.
It was only made sure that KLEE test compiles in non-KLEE mode, not that
something works or that KLEE is able to run tests.
First stage: something compiling without klee, but with a buch of dirty
hacks - done.
Second stage: something running under klee, able to emit useful results,
but still using dirty hacks - done.
Third stage: make CMake care about clang argumnets - not done, may be
omitted if proves to be too hard. Not that klee can be run on CI in any
case.
Currently supported nodes:
- Register as it is one of the simplest value nodes (even numbers are
not that simple with that dot handling).
- Plus, both unary and binary.
- Parenthesis, both nesting and calling.
Note regarding unit tests: it stores data for AST in highlighting in
strings in place of tables because luassert fails to do a good job at
representing big tables. Squashing a bunch of data into a single string
simply yields more readable result.
First intended to provide %r functionality like in Python (and also support for
%*.*s, but this was not checked), second adds nice table formatting for use in
cases similar to screen:snapshot_util().
> The option 'maxmem' ('mm') is used to set the maximum memory used for one
> buffer (in kilobytes). 'maxmemtot' is used to set the maximum memory used for
> all buffers (in kilobytes). The defaults depend on the system used. These
> are not hard limits, but tell Vim when to move text into a swap file. If you
> don't like Vim to swap to a file, set 'maxmem' and 'maxmemtot' to a very large
> value. The swap file will then only be used for recovery. If you don't want
> a swap file at all, set 'updatecount' to 0, or use the "-n" argument when
> starting Vim.
On today's systems these values are huge (4GB in my machine with 8GB of RAM
since it's set as half the available memory by default) so the limits are
never reached in practice, but Vim wastes a lot of time checking if the limit
was reached.
If the limit is reached Vim starts saving pieces of the swap file that were in
memory to the disk. Said in a different way: Vim implements its own memory
swapping mechanism. This is unnecessary and inefficient since the operating
system already virtualized the memory and will swap to the disk if programs
start using too much memory.
This change does...
1. Reduce the number of config options and need for documentation.
2. Make the code more efficient as we don't have to keep track of memory usage
nor check if the memory limits were reached to start swapping to disk every
time we need memory for buffers.
3. Simplify the code. Once `memfile.c` is simple enough it could be replaced by
actual operating system memory mapping (`mmap`, `MemoryViewOfFile`...).
This change does not prevent Vim to recover changes from swap files since the
swapping code is never triggered with the huge limits set by default.
Problem: as fileio is cached and reads blocks this is going to wait
until either EOF or reading enough characters to fill rbuffer. This is
not good when reading user input from stdin as script.
This variant uses `fdopen()` which is not standard, but it fixes problem on my
system. In next commit `scriptin` will use `FileDescriptor*` from os/fileio in
place of `FILE*`.
" - "# HG changeset patch" in first line (Mercurial export format)
elseifs:line1=~'^\(diff\>\|Only in \|\d\+\(,\d\+\)\=[cda]\d\+\>\|# It was generated by makepatch \|Index:\s\+\f\+\r\=$\|===== \f\+ \d\+\.\d\+ vs edited\|==== //\f\+#\d\+\|# HG changeset patch\)'
\ ||(s:line1=~'^--- ' && s:line2=~'^+++ ')
\ ||(s:line1=~'^\* looking for ' && s:line2=~'^\* comparing to ')
elseifs:line1=~#'^\(diff\>\|Only in \|\d\+\(,\d\+\)\=[cda]\d\+\>\|# It was generated by makepatch \|Index:\s\+\f\+\r\=$\|===== \f\+ \d\+\.\d\+ vs edited\|==== //\f\+#\d\+\|# HG changeset patch\)'
\ ||(s:line1=~#'^--- ' && s:line2=~#'^+++ ')
\ ||(s:line1=~#'^\* looking for ' && s:line2=~#'^\* comparing to ')
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
