These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
problem: most shada entries use weird `PossiblyFreedShadaEntry` type
solution: delet it
Shada entries can either be allocated by shada.c when reading,
or be constructed to represent the state of the current instance,
with direct references to live instance data to avoid extra allocations.
shada.c needs to carefully only free memory allocated by the first case,
and not free memory owned by other subsystems.
In some part of the code, this is inferred by the context but in others
we are mixing entries from different sources and need to indicate
the provenance by a `can_free_entry` flag. However constantly
frontloading this distinction in the name of the type and with
extra nesting levels, cause extra cognitive overhead when trying
to understand the code in any other aspects than the specific detail
of avoiding leaks/double frees.
As we always know if the memory is owned or not for any entry, we
can just put `can_free_entry` directly on the ShadaEntry struct.
That only one state is possible in a given context, is indicated
by this neat little syntactical construct called a constant field
initializer.
Using the preprocessor before generating prototypes provides some
"niceties" but the places that rely on these are pretty few.
Vastly simplifying the BUILD SYSTEM is a better trade-off.
Unbalancing { } blocks due to the preprocessor is cringe anyway (think
of the tree-sitter trees!), write these in a different way.
Add some workarounds for plattform specific features.
INCLUDE_GENERATED_DECLARATIONS flag is now technically redundant,
but will be cleaned up in a follow-up PR as it is a big mess.
Problem: Viminfo support is spread out.
Solution: Move more viminfo code to viminfo.c. (Yegappan Lakshmanan,
closesvim/vim#4717) Reorder code to make most functions static.
c3328169d5735aa4c4c8 was the partial port for
the typedefs.
This patch completes the viminfo->shada port.
- get_shada_parameter()
- find_shada_parameter()
Other patches below are N/A.
vim-patch:8.1.1728: wrong place for command line history viminfo support
Problem: Wrong place for command line history viminfo support.
Solution: Move it to viminfo.c.
5f32ece459
vim-patch:8.1.1730: wrong place for mark viminfo support
Problem: Wrong place for mark viminfo support.
Solution: Move it to viminfo.c. (Yegappan Lakshmanan, closesvim/vim#4716)
1e78e69680
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Shada jumplist entries still include entries from e.g. 'nobuflisted' buffers.
Solution: Check `ignore_buf()` before adding jumplist entries, followup to b98eefd8.
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Problem: too many strlen() calls
Solution: Change expand_env() to return string length
(John Marriott)
This commit does the following changes:
- In expand_env_esc():
- return the length of the returned dst string.
- refactor to remove some calls to STRLEN() and STRCAT()
- add check for out-of-memory condition.
- Change call sites in various source files to use the return value
closes: vim/vim#17561fff0132399
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: When ignore_buf skips buffers during initialization,
shada_read_when_writing uses entry.data.filemark.fname directly
as map key, but later frees the entry, leaving dangling pointers.
Solution: Always create independent copies of filenames as map keys
using xstrdup() for new items, and free all keys during cleanup.
Fix#34440
Problem: 'nobuflisted' buffers are incorrectly added to v:oldfiles.
Solution: Use ignore_buf() consistently in shada_write() for buffer
marks processing.
I guess these kinds of DRY techniques are kinda cutesy but unfortunately
I cannot expand macros invoking macros with various kind of syntax
fragments and back-references to local variables, at the same time
as I try to understand what is actually going on when you :wshada or :rshada
your jump marks, some of which having fname:s in them and some not.
This replaces it with four spelled out loops, although it is fine to
keep the memmove() related code generic in the item size just by passing a
runtime parameter (we have generics at home). Galaxy brain -03 -flto compilers
are gonna inline it anyway if it is worth it.
Problem: read/write shada function logic was skipped entirely if it was
detected the shadafile option was set to 'NONE'.
Solution: The filename is now always resolved. When the shadafile option
is set to 'NONE' AND no filename was passed, the filename resolves to an
empty string, which causes the read/write functions to return.
Regardless of whether the option is set to 'NONE', when a filename is
explicitly passed, it gets resolved and the read/write logic is
accessed.
Problem: too many strlen() calls in register.c
Solution: refactor code, add string_T struct to keep track
of string lengths (John Marriott)
closes: vim/vim#1595279f6ffd388
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: too many strlen() calls in cmdhist.c
Solution: refactor code and remove strlen() calls
(John Marriott)
closes: vim/vim#158888df07d0ca3
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem:
Index for global and numbered marks out of bounds when indexing into
numbered marks array (contains 10 elements but indexed by values 26 through 35.
Solution:
Offset index by number of global marks to correctly index numbered marks array.
Problem:
There appears to be an intentional array out of bounds read when
indexing global and numbered marks since they are adjacent in the struct
that holds them.
Solution:
Explicitly index numeric marks array to avoid reading out of bounds from
global marks array.
In the api_info() output:
:new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
...
{'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}
The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.
This also makes shada reading slightly faster due to avoiding
some copying and allocation.
Use keysets to drive decoding of msgpack maps for shada entries.
`FileDescriptor` is already a wrapper around an fd and a buffer.
By allowing to just use the buffer without an fd, it can
already handle in-memory reads.
Before, we needed to always pack an entire msgpack_rpc Object to
a continous memory buffer before sending it out to a channel.
But this is generally wasteful. it is better to just flush
whatever is in the buffer and then continue packing to a new buffer.
This is also done for the UI event packer where there are some extra logic
to "finish" of an existing batch of nevents/ncalls. This doesn't really
stop us from flushing the buffer, just that we need to update the state
machine accordingly so the next call to prepare_call() always will
start with a new event (even though the buffer might contain overflow
data from a large event).
writer is only ever used with FileDescriptor. We already have separate
code paths for serializing shada data into memory, see
shada_encode_regs() and friends
Functions like file_open_new() and file_open_fd_new() which just is a
wrapper around the real functions but with an extra xmalloc/xfree around
is an anti-pattern. If the caller really needs to allocate a
FileDescriptor as a heap object, it can do that directly.
FileDescriptor by itself is pretty much a pointer, or rather two:
the OS fd index and a pointer to a buffer. So most of the time an extra
pointer layer is just wasteful.
In the case of scriptin[curscript] in getchar.c, curscript used
to mean in practice:
N+1 open scripts when curscript>0
zero or one open scripts when curscript==0
Which means scriptin[0] had to be compared to NULL to disambiguate the
curscript=0 case.
Instead, use curscript==-1 to mean that are no script,
then all pointer comparisons dissappear and we can just use an array of
structs without extra pointers.
Note: kSDItemHeader is something is _written_ by nvim in the shada file
to identify it for debugging purposes outside of nvim. But this data wasn't ever used by
neovim after reading the file back, So I removed the parsing of it for now.
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
Problem: Set_ref_in_list() only sets ref in items.
Solution: Rename to set_ref_in_list_items() to avoid confusion.
7be3ab2589
Omit set_ref_in_list() and set_ref_in_dict(): only used in popup window,
if_pyth and if_lua.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
FUNC_ATTR_* should only be used in .c files with generated headers.
Defining FUNC_ATTR_* as empty in headers causes misuses of them to be
silently ignored. Instead don't define them by default, and only define
them as empty after a .c file has included its generated header.
Enable all clang-tidy warnings by default instead of disabling them.
This ensures that we don't miss useful warnings on each clang-tidy
version upgrade. A drawback of this is that it will force us to either
fix or adjust the warnings as soon as possible.
