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.
