| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
also: various other cleanup
|
| |
|
|
|
|
|
|
|
| |
- Replace obvious cases of '/' literal with PATHSEP. (There are still
some remaining cases that need closer inspection.)
- Fixup tests: ui/screen_basic
closes #7117
ref https://github.com/neovim/neovim/issues/2471#issuecomment-271193714
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #4370
Explication:
In the backtrace in #4370, we see that `buf_write()` was called with
non-NULL `fname` and `sfname` arguments, but they've since _become_
NULL.
#7 0x00000000004de09d in buf_write (buf=0x1dee040, fname=0x0, fname@entry=0x1e985b0 "/home/sean/src/github.com/snczl/virta/pkg/meld/segment.go",
sfname=0x0, sfname@entry=0x1ddfa60 "segment.go", start=1, end=72, eap=eap@entry=0x7ffc6b032e60, append=0,
forceit=0, reset_changed=1, filtering=0)
at /home/travis/build/neovim/bot-ci/build/neovim/src/nvim/fileio.c:2576
This is most likely due to the code that restores those values from
`buf`, which happens just before the fatal call to `os_fileinfo`
```c
/*
* The autocommands may have changed the name of the buffer, which may
* be kept in fname, ffname and sfname.
*/
if (buf_ffname)
ffname = buf->b_ffname;
if (buf_sfname)
sfname = buf->b_sfname;
if (buf_fname_f)
fname = buf->b_ffname;
if (buf_fname_s)
fname = buf->b_sfname;
```
It's worth noting that at this point `ffname` is still non-NULL, so
it _could_ be used. However, our current code is purely more strict
than Vim in this area, which has caused us problems before (e.g.,
`getdigits()`). The commentary for `struct file_buffer` clearly
indicate that all of `b_ffname`, `b_sfname`, and `b_fname` may be
NULL:
```c
/*
* b_ffname has the full path of the file (NULL for no name).
* b_sfname is the name as the user typed it (or NULL).
* b_fname is the same as b_sfname, unless ":cd" has been done,
* then it is the same as b_ffname (NULL for no name).
*/
char_u *b_ffname; /* full path file name */
char_u *b_sfname; /* short file name */
char_u *b_fname; /* current file name */
```
Vim directly calls `stat(2)` which, although it is annotated to tell
the compiler that the path argument is non-NULL, does handle a NULL
pointer by returning a `-1` value and setting `errno` to `EFAULT`.
This satisfies Vim's check, since it treats any `-1` return from
`stat(2)` to mean the file doesn't exist (at least in this code
path).
Note that Vim's mch_stat() implementations on win32 and solaris
clearly cannot accept NULL `name`. But the codepaths that call
mch_stat will NULL `name` tend to be unix-only (eg: u_read_undo)!
|
| |
|
|
| |
Code imported from #6299
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
Running this test with a mocked passwd file whose $HOME was set to
/home/jamessan/src/debian.org/pkg-vim/deb-packages/neovim/neovim-0.2.0/debian/fakehome
caused the test to fail, since the expanded result was >= 99 bytes. The
test should be reflecting the actual size of the buffer, instead of some
arbitrary other number, anwyay.
|
| | |
|
| |
|
|
|
|
|
| |
If procfs is missing then libuv cannot find the exe path.
Fallback to path_guess_exepath(), adapted from Vim findYourself().
Closes #6734
|
| | |
|
| | |
|
| |
|
|
| |
If the CWD contains a directory with the literal name "~" then the tests
will have bogus failures.
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not using enum{} because SIZE_MAX exceeds integer and I do not really like how
enum definition is described in C99:
1. Even though all values must fit into the chosen type (6.7.2.2, p 4) the type
to choose is still implementation-defined.
2. 6.4.4.3 explicitly states that “an identifier declared as an enumeration
constant has type `int`”. So it looks like “no matter what type was chosen
for enumeration, constants will be integers”. Yet the following simple
program:
#include <stdint.h>
#include <stdio.h>
#include <stddef.h>
enum { X=SIZE_MAX };
int main(int argc, char **argv)
{
printf("x:%zu m:%zu t:%zu v:%zu",
sizeof(X), sizeof(SIZE_MAX), sizeof(size_t), (size_t)X);
}
yields one of the following using different compilers:
- clang/gcc/pathcc: `x:8 m:8 t:8 v:18446744073709551615`
- pcc/tcc: `x:4 m:8 t:8 v:1844674407370955161`
If I remove the cast of X to size_t then pcc/tcc both yield `x:4 m:8 t:8
v:4294967295`, other compilers’ output does not change.
All compilers were called with `$compiler -std=c99 -xc -` (feeding program
from echo), except for `tcc` which has missing `-std=c99`. `pcc` seems to
ignore the argument though: it is perfectly fine with `-std=c1000`.
|
| | |
|
| |\
| |
| | |
unittests: Force GC, fix GC failures in typval_spec
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Not sure whether this is going to fix things though, but core dump does not
contain Neovim functions in stack in this case.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Benchmarks:
Before change: 17.78s user 3.48s system 94% cpu 22.525 total
After change: 25.38s user 4.46s system 101% cpu 29.317 total
|
| |\
| |
| | |
eval,fileio: Omit additional fsync() call
|
| | |
| |
| |
| | |
Fixes #6420
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Some benchmarks:
TRACE_EVERYTHING: 79.45s user 12.68s system 124% cpu 1:13.94 total
(default): 30.26s user 5.30s system 89% cpu 39.663 total
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some benchmarks:
MAIN_CDEFS + NO_TRACE: 3.81s user 1.65s system 33% cpu 16.140 total
MAIN_CDEFS: 73.61s user 10.98s system 154% cpu 54.690 total
NO_TRACE: 18.49s user 4.30s system 73% cpu 30.804 total
(default): 77.11s user 14.74s system 126% cpu 1:12.79 total
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
| |
Also removes NULL key input: tv_dict_find() does not allow this.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
