A single line was deleted from `ex_drop()` in 1a91000 when fixing clint
warnings causing the `:drop` command to not work correctly if the buffer
is not already open in a window.
Fixes#4981
Only update some entries that are already in `version.c`. Mercilessly stolen from https://github.com/neovim/neovim/pull/4634. At least one possible contributor got confused by it not being as-up-do-date-as-it-coul-be(tm). We shouldn't have that.
1005, 1010: :smile
1039: small Build
1058, 1073, 1079, 1097: alloc
1555, 1556, 1573: Makefile
1560, 1579: channel
Also adds one exception to linter rules:
typedef struct {
kvec_t(Object) stack;
} EncodedData;
is completely valid (from the style guide point of view) code.
It appears that used msgpack library is not able to parse back message created
by msgpack_rpc_from_object() if nesting level is too high, so log_server_msg now
cares about msgpack_unpack_next() return value. Also error message from
server_notifications_spec.lua is not readable if something is wrong (though at
least now it does not crash when parsing deeply nested structures).
log_server_msg() in the test reports
[msgpack-rpc] nvim -> client(1) [error] "parse error"
This removes some stack overflows in new test regarding deeply nested variables.
Now in place of crashing vim_to_object/msgpack_rpc_from_object/etc it crashes
clear_tv with stack overflow.
This ought to prevent stack overflow, but I do not see this actually working:
*lua* code crashes with stack overflow when trying to deserialize msgpack from
Neovim, Neovim is fine even if nesting level is increased 100x (though test
becomes very slow); not sure how recursive function may survive this. So it
looks like there are currently only two positive effects:
1. NULL lists are returned as empty (#4596).
2. Functional tests are slightly more fast. Very slightly. Checked for Release
build for test/functional/eval tests because benchmarking of debug mode is
not very useful.
Actual value on FreeBSD is -31, UV_EMLINK was obtained from
/usr/include/asm-generic/errno-base.h (there EMLINK is defined as 31 there).
This may actually be something else, but I do not think so as “Too many links”
description also fits in. [Man page][1] agrees with me, search for `[EMLINK]`
([linux man page][2] also specifies ELOOP explicitly in a similar section).
[1]: https://www.freebsd.org/cgi/man.cgi?query=open&sektion=2
[2]: http://man7.org/linux/man-pages/man3/open.3p.html
