cb02137dfa had two mistakes, of the same nature: trans_special() must
be invoked with in_string=false unless the parsing context is a VimL
string. replace_termcodes() and input_enqueue() are low-level
mechanisms where VimL strings do not exist.
keymap.c: adjust double-quote case to satisfy keymap_spec.lua
closes#7410
Reason: test may contain cleanup at the endwhich is needed for GC to work
properly, but is not done if test fails. With collectgarbage() in former
position it would crash when collecting garbage.
When building with certain GCC versions, a _Float128 type is present
when setting up the ffi for unit tests.
./test/unit/helpers.lua:256: declaration specifier expected near '_Float128' at line 396
/usr/bin/luajit: /usr/share/lua/5.1/busted/runner.lua:99: attempt to concatenate local 'message' (a table value)
stack traceback:
/usr/share/lua/5.1/busted/runner.lua:99: in function 'fn'
/usr/share/lua/5.1/mediator.lua:103: in function 'publish'
/usr/share/lua/5.1/busted/modules/helper_loader.lua:21: in function 'helperLoader'
/usr/share/lua/5.1/busted/runner.lua:147: in function </usr/share/lua/5.1/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: at 0x004044a0
CMake Error at /<<PKGBUILDDIR>>/cmake/RunTests.cmake:53 (message):
Running unit tests failed with error: 1.
Since this is being pulled in by a dependency, not directly used by
nvim, just ignore the type.
Closes#7423
Note: formatc.lua was unable to swallow some newer additions to ExprASTNodeType
(specifically `kExprNodeOr = '|'` and probably something else), so all `= …`
were dropped: in any case they only were there in order to not bother updating
viml_pexpr_debug_print_ast_node and since it is now known all nodes which will
be present it is not much of an issue.
It also adds support for kExprLexOr which for some reason was forgotten.
It was only made sure that KLEE test compiles in non-KLEE mode, not that
something works or that KLEE is able to run tests.
Currently supported nodes:
- Register as it is one of the simplest value nodes (even numbers are
not that simple with that dot handling).
- Plus, both unary and binary.
- Parenthesis, both nesting and calling.
Note regarding unit tests: it stores data for AST in highlighting in
strings in place of tables because luassert fails to do a good job at
representing big tables. Squashing a bunch of data into a single string
simply yields more readable result.
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)!
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.
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`.
