Contains unfinished attempt to integrate IWYU (ref #549). To finish it different
job should be done, specifically:
- Instead of feeding IWYU with modified file a mirror source tree should be
created with the help of CMake which will contain modified sources. This
solves the problem with IWYU thinking that `*.generated.h` headers should be
included in place of `*` headers.
- Build IWYU as all other third-party utilities.
- Make modified sources avoid problems with `nvim/func_attr.h` includes and
various related tricks.
Current script may only be used for manual checks like this:
./scripts/check-includes.py \
--generated-includes-dir build/include \
--generated-includes-dir build/src/nvim/auto \
--file src/nvim/eval/typval.c \
-- -Isrc -Ibuild/include -Ibuild/src/nvim/auto \
-DINCLUDE_GENERATED_DECLARATIONS
(it is also somewhat fine with `--file src/nvim/eval/typval.h`). I have no idea
why (I mean, why developer think that these lines are needed, why they are
suggested is pretty obvious: because there is typedef which mentions them before
structs are defined), but for typval.h it reports, among other things, that it
should add lines
struct dictvar_S;
struct listitem_S;
struct listvar_S;
struct listwatch_S;
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.
Reasoning; currently INTERNAL_CALL is mostly used to determine whether it is
needed to deal with NL-used-as-NUL problem. This code is useful for nvim_… API
calls done from VimL, but not for API calls done from lua, yet lua needs to
supply something as channel_id.
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.
No tests yet, no documentation update, no :lua* stuff, no vim module.
converter.c should also work with typval_T, not Object.
Known problem: luaeval("1", {}) results in
PANIC: unprotected error in call to Lua API (attempt to index a nil value)
Ref #3823
It's important that users have a single, easy-to-remember place for
reading about the API. So this commit changes gen_api_vimdoc.py so that
the generated section is appended to api.txt instead of creating
a separate document.
Also remove the section numbering and ToC: it's a maintenance cost, and
it will be unnecessary when #5169 is integrated.
It's not atypical to have extra, non-"vim-patch" commits in a PR merging
a bigger or set of related patches from Vim. Rather than immediately
aborting, display the patch header to the user and let them decide
whether to continue reviewing.
grep 2.26 changed its behavior when redirecting its output to /dev/null
such that it exits as soon as one match is found. This causes sed to
get a SIGPIPE which, due to "set -o pipefail", falsely implies that the
patch is not applied.
Removing "set -o pipefail" preserves the good exit status from grep.
