vim-patch:8.0.0431: 'cinoptions' cannot set indent for extern block
Problem: 'cinoptions' cannot set indent for extern block.
Solution: Add the "E" flag in 'cinoptions'. (Hirohito Higashi)
7720ba8599
Problem: The effect of adding "vim/vim#" to 'cinoptions' is not always removed.
(David Briscoe)
Solution: Reset b_ind_hash_comment. (Christian Brabandt, closesvim/vim#1475)
6b64394f34
Problem: When a C preprocessor statement has two line continuations the
following line does not have the right indent. (Ken Takata)
Solution: Add the indent of the previous continuation line. (Hirohito
Higashi)
c6aa475a27
Problem: C indenting does not support nested namespaces that C++ 17 has.
Solution: Add check that passes double colon inside a name. (Pauli, closes
vim/vim#1214)
ca8b8d6956
move `call_shell` to misc1.c
Move some fns to state.c
Move some fns to option.c
Move some fns to memline.c
Move `vim_chdir*` fns to file_search.c
Move some fns to new module, bytes.c
Move some fns to fileio.c
Problem: C indenting is wrong below a "case (foo):" because it is
recognized as a C++ base class construct. Issue #38.
Solution: Check for the case keyword.
d1b15dec4d
Problem: Indentation of array initializer is wrong.
Solution: Avoid that calling find_start_rawstring() changes the position
returned by find_start_comment(), add a test. (Hirohito Higashi)
089af18d1f
We already use wrappers for allocation, the new `xfree` function is the
equivalent for deallocation and provides a way to fully replace the malloc
implementation used by Neovim.
Problem : getdigits() currently returns a long, but at most places,
return value is casted (unsafely) into an int. Making casts
safe would introduce a lot of fuss in the form of assertions
checking for limits.
Note : We cannot just change return type to int, because, at some
places, legitimate long values are used. For example, in
diff.c, for line numbers.
Solution : Introduce new functions:
- get_digits() : Gets an intmax_t from a string.
- get_int_digits() : Wrapper for ints.
- get_long_digits() : Wrapper for longs.
And replace getdigits() invocations by the appropiate
wrapper invocations.
Problem: Using C indenting for Javascript does not work well for a {} block
inside parenthesis.
Solution: When looking for a matching paren ignore one that is before the
start of a {} block.
https://code.google.com/p/vim/source/detail?r=v7-4-350
A similar macro is defined in the Linux kernel [1].
To refactor the code I used a slightly modified Coccinelle script I found in
[2].
```diff
// Use the macro ARRAY_SIZE when possible
//
// Confidence: High
// Copyright: (C) Gilles Muller, Julia Lawall, EMN, DIKU. GPLv2.
// URL: http://www.emn.fr/x-info/coccinelle/rules/array.html
// Options: -I ... -all_includes can give more complete results
@@
type T;
T[] E;
@@
- (sizeof(E)/sizeof(*E))
+ ARRAY_SIZE(E)
@@
type T;
T[] E;
@@
- (sizeof(E)/sizeof(E[...]))
+ ARRAY_SIZE(E)
@@
type T;
T[] E;
@@
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
@n@
identifier AS,E;
@@
- #define AS(E) ARRAY_SIZE(E)
@@
expression E;
identifier n.AS;
@@
- AS(E)
+ ARRAY_SIZE(E)
```
`spatch --in-place --sp-file array_size.cocci -I src/ -I build/include/ -I build/src/nvim/auto/ src/nvim/*.c`
[1] http://lxr.free-electrons.com/source/include/linux/kernel.h#L54
[2] http://www.emn.fr/z-info/coccinelle/rules/#macros
- The 'stripdecls.py' script replaces declarations in all headers by includes to
generated headers.
`ag '#\s*if(?!ndef NEOVIM_).*((?!#\s*endif).*\n)*#ifdef INCLUDE_GENERATED'`
was used for this.
- Add and integrate gendeclarations.lua into the build system to generate the
required includes.
- Add -Wno-unused-function
- Made a bunch of old-style definitions ANSI
This adds a requirement: all type and structure definitions must be present
before INCLUDE_GENERATED_DECLARATIONS-protected include.
Warning: mch_expandpath (path.h.generated.h) was moved manually. So far it is
the only exception.
Problem: Now that nvim/strings.h is correctly namespaced, an issue
that had been masked until now arises:
When compiling, we get a lot of errors because of everywhere
the functions in nvim/strings.h are used, there's no include
to import them.
But, how could this compile and work previously, then? It
turns out that:
- In every such case, we are also including vim.h, which in
turn includes os_unix_defs.h.
- os_unix_defs.h includes <string.h> and also <strings.h> in
some systems (e.g. OSX).
- Build had been modified previously to (even when importing
system headers), prefer equally-named local ones. That was
in fact done as a previous attempt to solve the same issue
we are trying to solve another way now.
So, we were including our "strings.h" as a side-effect of
including <strings.h> through "vim.h" --> "os_unix_defs.h".
Solution: Correctly include "nvim/strings.h" in every file needing it.
Move files from src/ to src/nvim/.
- src/nvim/ becomes the new root dir for nvim executable sources.
- src/libnvim/ is planned to become root dir of the neovim library.
