| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
| |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
|
|
|
|
|
| |
update vendored libmpack-lua to match
https://github.com/libmpack/libmpack-lua/releases/tag/1.0.11
|
|
|
|
|
| |
problem: the api of vim.mpack is not compatible with a system provided mpack
solution: don't require 'mpack' directly from the system path
|
| |
|
| |
|
|
|
|
| |
This prevents `buflen` from becoming a very large number when it is 0
when calling mpack_rtoken().
|
|
|
|
|
|
|
|
|
|
|
| |
before, RelWithDebInfo linking gave this warning:
src/mpack/conv.h:36:16: warning: type of ‘mpack_unpack_boolean’ does not match original declaration [-Wlto-type-mismatch]
36 | MPACK_API bool mpack_unpack_boolean(mpack_token_t t) FUNUSED FPURE;
| ^
src/mpack/conv.c:196:16: note: return value type mismatch
196 | MPACK_API bool mpack_unpack_boolean(mpack_token_t t)
| ^
|
|
|
|
|
|
|
|
|
|
| |
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!).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored-by: Brede Yabo Sherling Kristensen <bredeyabo@hotmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: István Donkó <istvan.donko@gmail.com>
Co-authored-by: Julian Berman <Julian@GrayVines.com>
Co-authored-by: bryant <bryant@users.noreply.github.com>
Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com>
Co-authored-by: nlueb <9465658+nlueb@users.noreply.github.com>
Co-authored-by: Leonhard Saam <leonhard.saam@yahoo.com>
Co-authored-by: Jesse Wertheim <jaawerth@gmail.com>
Co-authored-by: dm1try <me@dmitry.it>
Co-authored-by: Jakub Łuczyński <doubleloop@o2.pl>
Co-authored-by: Louis Lebrault <louis.lebrault@gmail.com>
Co-authored-by: Brede Yabo Sherling Kristensen <bredeyabo@hotmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: István Donkó <istvan.donko@gmail.com>
Co-authored-by: Julian Berman <Julian@GrayVines.com>
Co-authored-by: bryant <bryant@users.noreply.github.com>
Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com>
Co-authored-by: nlueb <9465658+nlueb@users.noreply.github.com>
Co-authored-by: Leonhard Saam <leonhard.saam@yahoo.com>
Co-authored-by: Jesse Wertheim <jaawerth@gmail.com>
Co-authored-by: dm1try <me@dmitry.it>
Co-authored-by: Jakub Łuczyński <doubleloop@o2.pl>
Co-authored-by: Louis Lebrault <louis.lebrault@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
1. "unpack" has an unrelated meaning in Lua:
https://www.lua.org/manual/5.1/manual.html#pdf-unpack
2. We already have msgpackparse()/msgpackdump() and
json_encode()/json_decode(), so introducing another name for the same
thing is entropy.
Solution:
- Rename vim.mpack.pack/unpack => vim.mpack.encode/decode
Caveat:
This is incongruent with the `Unpacker` and `Packer` functions.
- It's probably too invasive to rename those.
- They also aren't part of our documented interface.
- This commit is "reversible" in the sense that we can always revert
it and add `vim.mpack.encode/decode` as _aliases_ to
`vim.mpack.pack/unpack`, at any time in the future, if we want
stricter fidelity with upstream libmpack. Meanwhile,
`vim.mpack.encode/decode` is currently the total _documented_
interface of `vim.mpack`, so this change serves the purpose of
consistent naming in the Nvim stdlib.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
b593809d93b5299bbee4e1d18e2e2d55f9fa53a6
|
|
22b1fd90285117c995728511f9525d29520a8c82
|