problem: can we have Serde?
solution: we have Serde at home
This by itself is just a change of notation, that could be quickly
merged to avoid messy merge conflicts, but upcoming changes are planned:
- keysets no longer need to be defined in one single file. `keysets.h` is
just the initial automatic conversion of the previous `keysets.lua`.
keysets just used in a single api/{scope}.h can be moved to that file, later on.
- Typed dicts will have more specific types than Object. this will
enable most of the existing manual typechecking boilerplate to be eliminated.
We will need some annotation for missing value, i e a boolean will
need to be represented as a TriState (none/false/true) in some cases.
- Eventually: optional parameters in form of a `Dict opts` final
parameter will get added in some form to metadata. this will require
a discussion/desicion about type forward compatibility.
Fix remaining clint errors and remove error suppression completely.
Rename the lint targets to align with the established naming convention:
- lintc-clint lints with clint.py.
- lintc-uncrustify lints with uncrustify.
- lintc runs both targets.
lintc is also provided as a make target for convenience.
After this change we can remove these files:
https://github.com/neovim/doc/tree/gh-pages/reports/clinthttps://github.com/neovim/doc/blob/main/ci/clint-errors.sh
Allow Include What You Use to remove unnecessary includes and only
include what is necessary. This helps with reducing compilation times
and makes it easier to visualise which dependencies are actually
required.
Work on https://github.com/neovim/neovim/issues/549, but doesn't close
it since this only works fully for .c files and not headers.
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
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
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
Asynchronous API functions are served immediately, which means pending
input could change the state of Nvim shortly after an async API function
result is returned.
nvim_get_mode() is different:
- If RPCs are known to be blocked, it responds immediately (without
flushing the input/event queue)
- else it is handled just-in-time before waiting for input, after
pending input was processed. This makes the result more reliable
(but not perfect).
Internally this is handled as a special case, but _semantically_ nothing
has changed: API users never know when input flushes, so this internal
special-case doesn't violate that. As far as API users are concerned,
nvim_get_mode() is just another asynchronous API function.
In all cases nvim_get_mode() never blocks for more than the time it
takes to flush the input/event queue (~µs).
Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if
e.g. `d` is operator-pending.
Closes#6159
Also re-word some error messages:
- "Key does not exist: %s"
- "Invalid channel: %<PRIu64>"
- "Request array size must be 4 (request) or 3 (notification)"
- "String cannot contain newlines"
References #6150
msgpack-c previously only had MSGPACK_OBJECT_FLOAT, which was a 64-bit
value. Now, 32-bit and 64-bit floats are supported as distinct types,
but we'll simply continue to treat everything as 64-bit types.
Fixes problem introduced by “api: Allow kObjectTypeNil to be zero without
breaking compatibility”: apparently there are clients which use metadata and
there are which aren’t. For the first that commit would not be needed, for the
second that commit misses this critical piece.
Now it checks functions also after every semicolon and closing figure brace,
possibly preceded by whitespaces (tabs and spaces). This should make messing
with declarations in macros not needed.
Function declarations generator is able to handle properly only the *first*
function definition that is in macros, and only if it is the first entity in the
macros. So msgpack_rpc_from_* was already really a static function, additionally
its attributes were useless. This commit switches to explicit declarations and
makes generated functions static.
During testing found the following bugs:
1. msgpack-gen.lua script is completely unprepared for Float values either in
return type or in arguments. Specifically:
1. At the time of writing relevant code FLOAT_OBJ did not exist as well as
FLOATING_OBJ, but it would be used by msgpack-gen.lua should return type
be Float. I added FLOATING_OBJ macros later because did not know that
msgpack-gen.lua uses these _OBJ macros, otherwise it would be FLOAT_OBJ.
2. msgpack-gen.lua should use .data.floating in place of .data.float. But it
did not expect that .data subattribute may have name different from
lowercased type name.
2. vim_replace_termcodes returned its argument as-is if it receives an empty
string (as well as _vim_id*() functions did). But if something in returned
argument lives in an allocated memory such action will cause double free:
once when freeing arguments, then when freeing return value. It did not cause
problems yet because msgpack bindings return empty string as {NULL, 0} and
nothing was actually allocated.
3. New code in msgpack-gen.lua popped arguments in reversed order, making lua
bindings’ signatures be different from API ones.
STR_CASE previously used a NULL data pointer for the String object, but
this pushes the NULL checks to the rest of the code. Instead,
allocating an empty string solves the same issue of there not being any
data but ensures that we're not passing NULL to functions that don't
expect it.
Closes#5627
Attempting to serialize a NULL string through msgpack results in
msgpack_sbuffer_write attempting to memcpy from a NULL pointer, which is
undefined behavior.
Since data.integer is a different (larger) integer type than
data.{buffer,window,tabpage}, we cannot abuse the union by using
data.integer to access the value for all 4 types. Instead, remove the
{buffer,window,tabpage} members and always use the integer member.
In order to accomodate this, perform distinct validation and coercion
between the Integer type and Buffer/Window/Tabpage types in
object_to_vim, msgpack_rpc helpers, and gendispatch.lua.
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.
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.
When converting a msgpack object to a String object, strings (and byte
arrays) with length 0 are handled as errors. This is fixed by
always using the msgpack data pointer as a valid pointer. For a NULL
pointer there is nothing to copy.
Test by @snoe
Fixes#3844
