Certain functions (e.g. feedkeys(…, 'x!') and input()) will attempt to
read from stdin, which shouldn't be expected to work during oldtests.
In Debian/Ubuntu's build environment, it explicitly can't work because
/dev/null is redirected to stdin, which causes read_error_exit() to
exit.
Running oldtests with --headless prevents nvim from setting up its input
handling, thus avoiding the problem altogether.
Reference #6794
vim-patch:8.0.0012
Problem: Typos in comments.
Solution: Change "its" to "it's". (Matthew Brener, closesvim/vim#1088)
9af4184276
vim-patch:8.0.0046
version.c: mark 8.0.0046 applied
vim-patch:8.0.0063
version.c: mark 8.0.0063 as NA patch
This delete() sometimes hangs the TSAN build. Work around it by using
a unique filename. Do it at the start instead of the end, for hygiene
(though it doesn't actually matter on CI, it helps local dev).
Coverity warning is a false positive: if rbuffer_read_ptr() returns
NULL then `cnt` is zero.
Revert 76ea97c809 (which caused
the TSan build to hang often--possibly because of the missing ui_flush()).
Instead, modify out_data_append_to_screen() to check for NULL.
ref #6862
Problem: OPEN_CHR_FILES not defined for FreeBSD using Debian userland
files.
Solution: Check for __FreeBSD_kernel__. (James McCoy, closesvim/vim#1166)
ca291aec99
Problem: getwinvar() returns wrong Value of boolean and number options,
especially non big endian systems. (James McCoy)
Solution: Cast the pointer to long or int. (closesvim/vim#1060)
789a5c0e3d
17:25:45,363 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/ex_getln.c: In function ‘color_cmdline’:
17:25:45,363 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/ex_getln.c:2335:8: error: variable ‘printed_errmsg’ set but not used [-Werror=unused-but-set-variable]
17:25:45,363 WARN - bool printed_errmsg = false;
17:25:45,363 WARN - ^
17:25:45,399 WARN - cc1: all warnings being treated as errors
Problem: A string argument for function() that is not a function name
results in an error message with NULL. (Christian Brabandt)
Solution: Use the argument for the error message.
5582ef1438
The issue with debug mode was actually not cleaning up after `try_enter`:
location `&tstate` was pointing to got invalidated and received some “garbage”
(actually, values that got stored on the stack afterwards). But pointer to that
garbage was still stored in `msg_list`, so next attempt to check it resulted in
a crash.
