https://neovim.io/develop/style-guide.xml#Horizontal_Whitespace
Note that this errors out for e.g.
if (has_mbyte) mb_copy_char((const char_u **)(&f), &t); \
(found in macros.h:151) or
#define ECMD_SET_HELP 0x02 /* set b_help flag of (new) buffer before
(found in ex_cmds.h:11) (note `(new) buffer`). I left this as-is because these
pieces of code are already caught by another rule (braces near if and `/*`-style
comments). Other false positives I found were:
1. `FUNC_ATTR_NONNULL_ARG(1) FUNC_ATTR_WARN_UNUSED_RESULT`: rejected by
requiring type name to start with `[a-zA-Z_]` (this makes `1` not be
incorrectly recognized as a type).
2. `#define FOO(var) (var)`: rejected by creating `cast_line`.
3. `(expr) * (expr)`: rejected by constructing regexp so that unary operators
require no spaces after them.
4. `int f(void) FUNC_ATTR_PURE`: rejected by requiring line to start with
a space.
5. `"." STR(NVIM_VERSION_PATCH) NVIM_VERSION_PRERELEASE`: not rejected, such
thing should be rare and it would be easy to get rid of the false positive by
e.g. breaking line.
Struct literals like `(MyStruct) { 4, 2 }` are not checked:
1. I am not sure whether they are under this rule at all (this is not a cast).
2. It would be hard to get rid of false positives (like the example with `if`
above, but now for *valid* `if() {}`s).
When skipping these test blocks they may error out:
Error → test/functional/shell/viml_system_spec.lua @ 154
system() with output containing NULs setup
./test/functional/helpers.lua:75: attempt to index upvalue 'session' (a nil value)
stack traceback:
./test/functional/helpers.lua:75: in function 'request'
./test/functional/helpers.lua:166: in function 'nvim_feed'
./test/functional/helpers.lua:195: in function 'feed'
test/functional/shell/viml_system_spec.lua:14: in function <test/functional/shell/viml_system_spec.lua:13>
Error → test/functional/shell/viml_system_spec.lua @ 155
system() with output containing NULs teardown
./test/functional/helpers.lua:75: attempt to index upvalue 'session' (a nil value)
stack traceback:
./test/functional/helpers.lua:75: in function 'eval'
test/functional/shell/viml_system_spec.lua:21: in function <test/functional/shell/viml_system_spec.lua:20>
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
Problem: Autocommands triggered by quickfix cannot always get the current
title value.
Solution: Call qf_fill_buffer() later. (Christian Brabandt)
6920c72d4d
Helped by @mhinz
Updated runtime files.
e0fa3742ea
Ignore changes to
* doc/channel.txt: Channel related docs
* doc/netbeans.txt, doc/os_dos.txt, doc/todo.txt: Not relevant to Neovim
* doc/tags: Generated at build time
Update runtime files.
38a55639d6
Ignore changes to
* doc/channel.txt, doc/eval.txt, doc/various.txt: Channel related docs
* doc/tags: Generated at build time
* doc/todo.txt, doc/vi_diff.txt: Not relevant to neovim
Updated runtime files.
cbebd4879c
Ignore changes to
* doc/channel.txt, doc/eval.txt: Channel related docs
* doc/tags: Generated at build time
* doc/todo.txt: Not relevant to Neovim
* ftplugin/man.vim: Change already present in autoload/man.vim
Update runtime files.
681baaf4a4
Ignore changes to
* doc/channel.txt, doc/eval.txt, doc/usr_41.txt: Channel related docs
* doc/tags: Generated at build time
* doc/todo.txt: Not relevant to Neovim
Updated runtime files and translations.
5e9b2fa9bb
Ignore changes to
* doc/tags: generated at build time
* doc/develop.txt, doc/todo.txt, doc/netbeans.txt, doc/vim-ja.UTF-8.1,
doc/xxd-ja.UTF-8.1, lang/menu_*: Not applicable to Neovim
* doc/editing.txt: Crypt related
* doc/change.txt, doc/insert.txt, doc/various.txt: Removal of ex_extra
tags, which already happened in Neovim
* doc/vim-ja.UTF-8.1, doc/xxd-ja.UTF-8.1
This avoids the issue of nvim started daemons causing mountpoints to be
unmountable. This is currently the only place in runtime/ where this
calling convention occurred.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
