| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
| |
Result of `make iwyu` (after some "fixups").
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
- "process" is often used as a verb (`multiqueue_process_events`), which
is ambiguous for cases where it's used as a topic.
- The documented naming convention for processes is "proc".
- `:help dev-name-common`
- Shorter is better, when it doesn't harm readability or
discoverability.
Solution:
Rename "process" => "proc" in all C symbols and module names.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Followup to #28515:
Rename the static os_homedir() to os_uv_homedir() to emphasize that it
is a wrapper around a libuv function.
Add the function os_get_homedir() to os/env.c to return the cached
homedir value as a const. Must be called after homedir is initialized or
it fails.
The difference between this function and the static os_uv_homedir() is
that the latter gets the homedir from libuv and is used to initialize
homedir in init_homedir(), while os_get_homedir() just returns homedir
as a const if it's initialized and is public.
Use the os_get_homedir() accessor for ~/ expansion on Windows to make
the code more concise.
Add a Windows section to main_spec.lua with tests for expanding ~/ and
~\ prefixes for files passed in on the command-line.
Signed-off-by: Rafael Kitover <rkitover@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use uv_fs_realpath() instead.
It seems that uv_fs_realpath() has some problems on non-Linux platforms:
- macOS and other BSDs: this function will fail with UV_ELOOP if more
than 32 symlinks are found while resolving the given path. This limit
is hardcoded and cannot be sidestepped.
- Windows: while this function works in the common case, there are a
number of corner cases where it doesn't:
- Paths in ramdisk volumes created by tools which sidestep the Volume
Manager (such as ImDisk) cannot be resolved.
- Inconsistent casing when using drive letters.
- Resolved path bypasses subst'd drives.
Ref: https://docs.libuv.org/en/v1.x/fs.html#c.uv_fs_realpath
I don't know if the old implementation that uses uv_chdir() and uv_cwd()
also suffers from the same problems.
- For the ELOOP case, chdir() seems to have the same limitations.
- On Windows, Vim doesn't use anything like chdir() either. It uses
_wfullpath(), while libuv uses GetFinalPathNameByHandleW().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no "rule" or bad practice or whatever that says we cannot
generate c files. it is is just that we have ~20 generated headers
and ~2 generated sources and there is nothing in these two generated
source files which sets them aparts. Lua bindings are not different from
rpc bindings, and pathdef is not different from versiondef.
So to simplify build logic and ease the future port to build.zig,
streamline the build to only have generated headers, no direct generated
.c files.
Also "nlua_add_api_functions" had its prototype duplicated twice which
defeated the point of having mandatory prototypes (one source of truth).
|
| |
|
|
|
|
| |
Problem: Using xstrlcpy() when the exact length of the string to be
copied is known is not ideal because it requires adding 1 to
the length and an unnecessary strlen().
Solution: Add xmemcpyz() and use it in place of such xstrlcpy() calls.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
colon (#27791)
Problem: expand() removes a slash after an environment variable that
ends with a colon on Windows.
Solution: Check the correct char for a colon (zeertzjq)
closes: vim/vim#14161
Note: Vim still removes the path-separator at the end, if another path separator
follows directly after it, e.g. on:
```
echo $FOO='/usr/'
echo expand('$FOO/bar') == '/usr/bar'
```
see:
,----[ misc1.c:1630 ]
| // if var[] ends in a path separator and tail[] starts
| // with it, skip a character
| if (after_pathsep(dst, dst + c)
| #if defined(BACKSLASH_IN_FILENAME) || defined(AMIGA)
| && (dst == save_dst || dst[-1] != ':')
| #endif
| && vim_ispathsep(*tail))
| ++tail;
`----
https://github.com/vim/vim/commit/13a014452a7a020a119ac555a690c65b41f3126d
Cherry-pick test_expand.vim change from patch 9.0.1257.
|
| |
|
|
|
|
|
|
| |
Problem: Various warnings from clang on MS-Windows.
Solution: Avoid the warnings. (Yegappan Lakshmanan, closes vim/vim#10553)
https://github.com/vim/vim/commit/a34b4460c2843c67a35a2d236b01e6cb9bc38734
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| |
|
|
|
|
|
|
|
|
| |
os_getenv("FOO") caches the result when $FOO is set to something
non-empty. However, when $FOO was not set, every new call to
os_getenv("FOO") would allocate a temporary scratch buffer to
immediately throw away.
This has an huge impact e.g. on logging which depends on potentially
non-set env vars.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Discovered using __sanitizer_print_memory_profile().
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
| |
|
|
| |
When the given length is exactly the number of bytes to copy, xmemdupz()
makes the intention clearer.
|
| | |
|
| |
|
|
|
|
| |
- Move vimoption_T to option.h
- option_defs.h is for option-related types
- option_vars.h corresponds to Vim's option.h
- option_defs.h and option_vars.h don't include each other
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involves two redesigns of the map.c implementations:
1. Change of macro style and code organization
The old khash.h and map.c implementation used huge #define blocks with a
lot of backslash line continuations.
This instead uses the "implementation file" .c.h pattern. Such a file is
meant to be included multiple times, with different macros set prior to
inclusion as parameters. we already use this pattern e.g. for
eval/typval_encode.c.h to implement different typval encoders reusing a
similar structure.
We can structure this code into two parts. one that only depends on key
type and is enough to implement sets, and one which depends on both key
and value to implement maps (as a wrapper around sets, with an added
value[] array)
2. Separate the main hash buckets from the key / value arrays
Change the hack buckets to only contain an index into separate key /
value arrays
This is a common pattern in modern, state of the art hashmap
implementations. Even though this leads to one more allocated array, it
is this often is a net reduction of memory consumption. Consider
key+value consuming at least 12 bytes per pair. On average, we will have
twice as many buckets per item.
Thus old implementation:
2*12 = 24 bytes per item
New implementation
1*12 + 2*4 = 20 bytes per item
And the difference gets bigger with larger items.
One might think we have pulled a fast one here, as wouldn't the average size of
the new key/value arrays be 1.5 slots per items due to amortized grows?
But remember, these arrays are fully dense, and thus the accessed memory,
measured in _cache lines_, the unit which actually matters, will be the
fully used memory but just rounded up to the nearest cache line
boundary.
This has some other interesting properties, such as an insert-only
set/map will be fully ordered by insert only. Preserving this ordering
in face of deletions is more tricky tho. As we currently don't use
ordered maps, the "delete" operation maintains compactness of the item
arrays in the simplest way by breaking the ordering. It would be
possible to implement an order-preserving delete although at some cost,
like allowing the items array to become non-dense until the next rehash.
Finally, in face of these two major changes, all code used in khash.h
has been integrated into map.c and friends. Given the heavy edits it
makes no sense to "layer" the code into a vendored and a wrapper part.
Rather, the layered cake follows the specialization depth: code shared
for all maps, code specialized to a key type (and its equivalence
relation), and finally code specialized to value+key type.
|
| |
|
|
| |
Notable changes: replace all infinite loops to `while(true)` and remove
`int` from `unsigned int`.
|
| |
|
|
|
| |
This was needed when TUI was a thread.
lua code uses os_getenv only on the main thread.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem: Vim9: no line break allowed inside a lambda.
Solution: Handle line break inside a lambda in Vim9 script.
https://github.com/vim/vim/commit/e40fbc2ca9fda07332a4da5af1fcaba91bed865b
Omit skip_expr_concatenate(). Apply the change to skip_expr() instead.
Omit eval_ga: Vim9 script only.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | |
|
| |
|
|
| |
Add const to char * parameters in message.c functions and remove some
redundant casts.
|
| | |
|
| |
|
|
|
|
| |
MSVC has 4 different warning levels: 1 (severe), 2 (significant), 3
(production quality) and 4 (informational). Enabling level 3 warnings
mostly revealed conversion problems, similar to GCC/clang -Wconversion
flag.
|
| |
|
|
|
| |
refactor: replace char_u with char
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
|
| |
refactor: replace char_u with char
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
| |
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
|
| |
refactor: replace char_u with char
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
|
| |
refactor: replace char_u with char
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
|
| |
refactor: replace char_u with char
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
| |
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
| |
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
| |
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
|
|
|
|
|
|
| |
Allow Include What You Use to remove unnecessary includes and only
include what is necessary. This helps with reducing compilation times
and makes it easier to visualise which dependencies are actually
required.
Work on https://github.com/neovim/neovim/issues/549, but doesn't close
it since this only works fully for .c files and not headers.
|
| |
|
|
|
|
|
|
| |
Enable and fix bugprone-misplaced-widening-cast warning.
Fix some modernize-macro-to-enum and readability-else-after-return
warnings, but don't enable them. While the warnings can be useful, they
are in general too noisy to enable.
|
| | |
|
| |
|
|
|
|
|
| |
Problem: Macros for MS-Windows are inconsistent, using "32", "3264 and
others.
Solution: Use MSWIN for all MS-Windows builds. Use FEAT_GUI_MSWIN for the
GUI build. (Hirohito Higashi, closes vim/vim#3932)
https://github.com/vim/vim/commit/4f97475d326c2773a78561fb874e4f23c25cbcd9
|
| |
|
|
| |
Work on https://github.com/neovim/neovim/issues/459
|
| |
|
|
| |
Work on https://github.com/neovim/neovim/issues/459
|
