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.
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).
