| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
yes NVIM_TEST_TRACE_LEVEL does exist but simply displaying the
stacktrace of the error should not be opt in. Now that we "own" the
harness we can borrow some harness code for the child to only print spec
file lines and not testutil lines.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Debian's ppc64el build, the unittests are failing during preprocess
with
test/unit/testutil.lua:298: declaration specifier expected near '__typeof' at line 298
test/unit/testutil.lua:282: assertion failed!
Running with NVIM_TEST_PRINT_I set shows these lines as being the
problem when trying to preprocess test/unit/fixtures/posix.h.
690 extern __typeof (strtold) strtold ;
691 extern __typeof (strtold_l) strtold_l ;
692 extern __typeof (strfroml) strfroml ;
693 extern __typeof (qecvt) qecvt ;
694 extern __typeof (qfcvt) qfcvt ;
695 extern __typeof (qgcvt) qgcvt ;
696 extern __typeof (qecvt_r) qecvt_r ;
697 extern __typeof (qfcvt_r) qfcvt_r ;
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
On "arm clang unittest" CI job, `make unittest` sometimes fails with
lots of these messages:
FAILED test/unit/testutil.lua @ 773: ...
test/unit/testutil.lua:773:
test/unit/testutil.lua:297: declaration specifier expected near '_Static_assert' at line 429
exit code: 256
stack traceback:
test/unit/testutil.lua:773: in function 'itp_parent'
test/unit/testutil.lua:811: in function <test/unit/testutil.lua:801>
Solution:
Update filter_complex_blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The Lua test harness still ran through standalone -ll mode, so tests
depended on the low-level Lua path instead of the regular Nvim Lua
environment. That also meant os.exit() coverage had to carry an ASAN
workaround because Lua's raw process exit skipped Nvim teardown and let
LeakSanitizer interfere with the observed exit code.
Solution:
Run the harness and related fixtures with nvim -l. Patch os.exit() in
the main Lua state to exit through getout(), so scripts observe normal
Nvim shutdown while standalone -ll remains available for generator-style
scripts. As a consequence, the startup test can assert os.exit() without
disabling leak detection.
AI-assisted: Codex
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the busted-based Lua test runner with a repo-local harness.
The new harness runs spec files directly under `nvim -ll`, ships its own
reporter and lightweight `luassert` shim, and keeps the helper/preload
flow used by the functional and unit test suites.
Keep the file boundary model shallow and busted-like by restoring `_G`,
`package.loaded`, `package.preload`, `arg`, and the process environment
between files, without carrying extra reset APIs or custom assertion
machinery.
Update the build and test entrypoints to use the new runner, add
black-box coverage for the harness itself, and drop the bundled
busted/luacheck dependency path.
AI-assisted: Codex
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
On macOS Tahoe, `make unittest` started failing with the following error.
````
test/unit/testutil.lua:784: test/unit/testutil.lua:768: (string) '
test/unit/testutil.lua:295: declaration specifier expected near 'ipc_info_object_type_t' at line 2297'
exit code: 256
stack traceback:
test/unit/testutil.lua:784: in function 'itp_parent'
test/unit/testutil.lua:822: in function <test/unit/testutil.lua:812>
````
Solution:
Update filter_complex_blocks.
|
| |
|
| |
This fixes the flaky eval/typval_spec.lua tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in #34908, the arm unittests fail due to unrecognized types:
ERROR test/unit/testutil.lua @ 802: Expressions parser works with &opt
test/unit/testutil.lua:774: test/unit/testutil.lua:758: (string) '
test/unit/testutil.lua:288: declaration specifier expected near '__SVFloat32_t''
exit code: 256
After testing on Debian's arm64 porterbox, the unittests cleanly pass
when ignoring various types defined in
/usr/include/aarch64-linux-gnu/bits/math-vector.h
|
| |
|
|
|
|
|
| |
Copy whatever was made to work for generated headers:
(1) we need to consider all cmake targets not just main_lib
(2) we need to add the sysroot for macOS
|
| | |
|
| |
|
|
|
|
|
|
| |
Problem: On 32-bit architectures, musl libc makes heavy use of
__typeof__ as part of its __REDIR macro for optional backwards
compatibility with 32-bit time_t values. Unfortunately, the
__typeof__ keyword is not supported by the LuaJIT C parser.
Solution: Filter out the keyword in filter_complex_blocks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: This keyword is used by GCC and Clang to prevent -Wpedantic
(and other options) from emitting warnings for many GNU C extensions.
This is used heavily in Alpine Linux through musl libc and
foritfy-headers. Without filtering the __extension__ keyword some type
definitions are duplicated. For example, timeval is defined once as
struct timeval { time_t tv_sec; suseconds_t tv_usec; };
and once as:
__extension__ struct timeval { time_t tv_sec; suseconds_t tv_usec; };
Without this patch, the LuaJIT C parser doesn't recognize that these
definitions are equivalent, causing unit test to fail on Alpine Linux.
Solution: Filter out the keyword in filter_complex_blocks.
|
| |
|
|
|
|
|
| |
These were imported from the v0.3.3 git tag
https://github.com/neovim/libvterm/tree/v0.3.3 and not the latest
commit. This is for compatibility reasons as the libvterm code was
imported from v0.3.3.
|
| |
|
|
| |
Most of the codebase uses the `M` convention for Lua module.
Update the last remaining cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more filters so that LuaJIT can parse headers on macOS 14.
The system headers use a style of enum introduced in C++11 (and allowed
as an extension in C by clang) of the form:
enum Name : Type {
The system headers also use bitfields in the mach_vm_range_recipe* types:
struct Foo { int bar : 32; }
Neither of these constructs can be parsed by LuaJIT, so filter the lines
out. Neither of these declarations are used by neovim's unittests.
There is a (now closed) issue about bitfields for LuaJIT:
https://github.com/LuaJIT/LuaJIT/issues/951
Fixes #26145.
|
| | |
|
|
|
Work on https://github.com/neovim/neovim/issues/27004.
|
