Note for external UIs: Nvim can now emit multiple "redraw" event batches
before a final "flush" event is received. To retain existing behavior,
clients should make sure to update visible state at an explicit "flush"
event, not just the end of a "redraw" batch of event.
* Get rid of copy_object() blizzard in the auto-generated ui_event layer
* Special case "grid_line" by encoding screen state directly to
msgpack events with no intermediate API events.
* Get rid of the arcane notion of referring to the screen as the "shell"
* Array and Dictionary are kvec_t:s, so define them as such.
* Allow kvec_t:s, such as Arrays and Dictionaries, to be allocated with
a predetermined size within an arena.
* Eliminate redundant capacity checking when filling such kvec_t:s
with values.
Problem:
- Unix sockets are created in random /tmp dirs.
- /tmp is messy, unclear when OSes actually clear it.
- The generated paths are very ugly. This adds friction to reasoning
about which paths belong to which Nvim instances.
- No way to provide a human-friendly way to identify Nvim instances in
logs or server addresses.
Solution:
- Store unix sockets in stdpath('state')
- Allow --listen "name" and serverstart("name") to given a name (which
is appended to a generated path).
TODO:
- is stdpath(state) the right place?
Problem:
1. Log messages (especially in CI) are hard to correlate with tests.
2. Since b353a5c05f#11886, dumplog() prints the logs next to test
failures. This is noisy and gets in the way of the test results.
Solution:
1. Associate an incrementing id with each test and include it in log
messages.
- FUTURE: add v:name so Nvim instances can be formally "named"?
2. Mention "child" in log messages if the current Nvim is a child (based
on the presence of $NVIM).
BEFORE:
DBG … 12345 UI: event
DBG … 12345 log_server_msg:722: RPC ->ch 1: …
DBG … 12345 UI: flush
DBG … 12345 inbuf_poll:444: blocking... events_enabled=1 events_pending=0
DBG … 23454 UI: stop
INF … 23454 os_exit:594: Nvim exit: 0
AFTER:
DBG … T57 UI: event
DBG … T57 log_server_msg:722: RPC ->ch 1: …
DBG … T57 UI: flush
DBG … T57 inbuf_poll:444: blocking... events_enabled=1 events_pending=0
DBG … T57/child UI: stop
INF … T57/child os_exit:594: Nvim exit: 0
drawback: tracing memory errors with ASAN is less accurate for arena
allocated memory.
Therefore, to start with it is being used for Object types around
serialization/deserialization exclusively. This is going to have
a large impact especially when TUI is refactored as a co-prosess
as all UI events will be serialized and deserialized by nvim itself.
Currently this is more or less a straight off reimplementation,
but this allow further optimizations down the line, especially
for avoiding memory allocations of rpc objects.
Current score for "make functionaltest; make oldtest" on a -DEXITFREE build:
is 117 055 352 xfree(ptr != NULL) calls (that's NUMBERWANG!).
Problem:
1. The main log routine does not protect itself against recursion.
log_lock() doesn't guard against recursion, it would deadlock...
2. 22b52dd462 (#11501) regressed 6f27f5ef91 (#10172), because
set_init_1..process_spawn tries to log (see backtrace below), but the
mutex isn't initialized yet. Even if the mutex were valid, we don't
want early logging to fallback to stderr because that can break
embedders when stdio is used for RPC.
frame 1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7
frame 2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20
frame : 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3
frame 4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5
frame 5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7
frame 6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3
frame 7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3
frame 8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18
frame 9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14
frame 10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7
...
frame 23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17
frame 24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3
frame 25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19
frame 26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3
frame 27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
Solution:
1. Check for recursion, show "internal error" message.
- FUTURE: when "remote TUI" is merged, can we remove log_lock()?
2. Skip logging if log_init wasn't called yet.
PROBLEM
------------------------------------------------------------------------
$NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the
current process should listen on this address") and a descriptor ("the
current process is a child of this address").
This contradiction means the presence of NVIM_LISTEN_ADDRESS is
ambiguous, so child Nvim always tries to listen on its _parent's_
socket. This is the cause of lots of "Failed to start server" spam in
our test/CI logs:
WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0
WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0
SOLUTION
------------------------------------------------------------------------
1. Set $NVIM to the parent v:servername, *only* in child processes.
- Now the correct way to detect a "parent" Nvim is to check for $NVIM.
2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes.
3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after
server init.
4. Open a channel to parent automatically, expose it as v:parent.
Fixes#3118Fixes#6764Fixes#9336
Ref https://github.com/neovim/neovim/pull/8247#issuecomment-380275696
Ref #8696
Add space around arithmetic operators '+' and '-'.
Remove space between back-to-back parentheses, i.e. ')(' vs. ') ('.
Remove space between '((' or '))' of control statements.
Add space between ')' and '{' of control statements.
Remove space between function name and '(' on function declaration.
Collapse empty blocks between '{' and '}'.
Remove newline at the end of the file.
Remove newline between 'enum' and '{'.
Remove newline between '}' and ')' in a function invocation.
Remove newline between '}' and 'while' of 'do' statement.
* refactor: format header files with uncrustify
* fixup(justin): skip formatting of terminfo_defs.h
* fixup: force winsock2 to be included first
* fixup: simplify disable/enable directive to "uncrustify:off/on"
Do not copy a lot of lua strings (dict keys) to just strequal() them
Just compare them directly to a dedicated hash function.
feat(generators): HASHY McHASHFACE
* refactor: format with uncrustify
* fixup(dundar): fix functions comments
* fixup(dundar): remove space between variable and ++/--
* fixup(dundar): better workaround for macro attributes
This is done to be able to better use uncrustify rules for macros
* fixup(justin): make preprocessors follow neovim style guide
* refactor: disable formatting for attribute in macro
* fixup: disable/enable uncrustify with uncrustify:indent-off/on
* fixup: stop indenting contents inside braces in case
* fixup: remove case brace if no variable declaration
Converter functions use a heap-allocated stack to handle complex
nested objects. However, these are often called with simple,
primitive values like integers or bools wrapped in an Object.
Avoid the memory allocation in this case using kvec_withinit_t
Note: the reason for removing them is not that there after this refactor
is no use of them, but rather that having them available is an
anti-pattern: they manange an _extra_ heap allocation which has
nothing to do with the functionality of the map itself (khash
manages the real buffers internally). In case there happens to
be a reason to allocate the map structure itself later, this
should be made explicit using xcalloc/xfree calls.
../src/nvim/event/rstream.c:119:44: warning: format specifies type 'void *' but the argument has type 'Stream *' (aka 'struct stream *') [-Wformat-pedantic]
DLOG("Closing Stream (%p): %s (%s)", stream,
~~ ^~~~~~
../src/nvim/event/stream.c:95:30: warning: format specifies type 'void *' but the argument has type 'Stream *' (aka 'struct stream *') [-Wformat-pedantic]
DLOG("closing Stream: %p", stream);
~~ ^~~~~~
../src/nvim/msgpack_rpc/channel.c:71:72: warning: format specifies type 'void *' but the argument has type 'Stream *' (aka 'struct stream *') [-Wformat-pedantic]
DLOG("rpc ch %" PRIu64 " in-stream=%p out-stream=%p", channel->id, in, out);
~~ ^~
../src/nvim/msgpack_rpc/channel.c:71:76: warning: format specifies type 'void *' but the argument has type 'Stream *' (aka 'struct stream *') [-Wformat-pedantic]
DLOG("rpc ch %" PRIu64 " in-stream=%p out-stream=%p", channel->id, in, out);
~~ ^~~
../src/nvim/msgpack_rpc/channel.c:226:28: warning: format specifies type 'void *' but the argument has type 'Stream *' (aka 'struct stream *') [-Wformat-pedantic]
channel->id, count, stream);
^~~~~~
According to [MessagePack RPC specification](https://github.com/msgpack-rpc/msgpack-rpc),
message ID must be 32-bit unsigned integer. But Neovim implementation
uses uint64_t instead of uint32_t. This can have wrong results in the
case of large ids or a malformed request, for example:
Actual response: [1,18446744073709551615,[1,"Message is not an array"],null]
Expected response: [1,4294967295,[1,"Message is not an array"],null]
The issue does not affect RPC clients written in dynamically-typed
languages like Python. Wrong type of sequence id number breaks RPC
clients written statically typed languages like C/C++/Golang: all of
them expect uint32_t as message id.
Examples:
11268ba2be/src/msgpack/rpc/protocol.h (L27)https://github.com/ugorji/go/blob/master/codec/msgpack.go#L993closes#8850
Using a sentinel value in the response-id is ambiguous because the
msgpack-rpc spec allows all values (including zero/max). And clients
control the id, so we can't be sure they won't use the sentinel value.
Instead of a sentinel value, check the message type explicitly.
ref #8850
Note about shada.c:
- shada_read_next_item_start was intentionally shadowing `unpacked` and
`i` because many of the macros (e.g. ADDITIONAL_KEY) implicitly
depended on those variable names.
- Macros were changed to parameterize `unpacked` (but not `i`). Macros
like CLEAR_GA_AND_ERROR_OUT do control-flow (goto), so any other
approach is messy.
Give embeders a chance to set up nvim, by processing a request before
startup. This allows an external UI to show messages and prompts from
--cmd and buffer loading (e.g. swap files)
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
