Commits


luajit: bump new version Fix C file generation in jit.bcsave. Add 'cc' file type for saving bytecode. test: set dependencies in BuildTestCLib macro Part of #9145 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump NO_CHANGELOG=LuaJIT submodule bump


test: remove LuaJIT-related CLI tests There are two reasons for this changeset: * The positive one: Tarantool supports -b and -j options to use LuaJIT modules since the commit bf8b76a4dfc9dd62d4131e90e2ae5d83843b6630 ("lua: proxy -j and -b flags"), so the related tests from lua-Harness suite can be partially (since -O option is still not implemented in Tarantool) enabled. * The negative one: Tarantool diff-based tests for CLI interfaces are hard to maintain, if any change occurs in LuaJIT modules, since the aforementioned tests implement dumb comparison of the output, produced by the current CLI version against the expected one, managed by the .result file. Hence, to rule the tests related to the LuaJIT CLI interface in a more convenient way, the corresponding tests should be moved from the tests in the Tarantool repository to the tests in the LuaJIT repository. The recent LuaJIT bump landed to the master in the scope of commit 0dcf675952fbb76d8cfb6de30b680451d56cdf43 ("luajit: bump new version") enables the nice checks implemented in the lua-Harness suite; this patch removes the barely maintainable diff-based tests from this repository. Follows up #5541 NO_DOC=test NO_CHANGELOG=test


luajit: bump new version * cmake: introduce AddTestLib macro * test: prepare lauxilarily libs for LuaJIT-tests * test: separate LuaJIT helpers from ffi_util.inc * test: enable <ffi_arith_ptr.lua> in LuaJIT-tests * test: enable <ffi_bitfield.lua> in LuaJIT-tests * test: enable <ffi_call.lua> in LuaJIT-tests * test: enable <ffi_callback.lua> in LuaJIT-tests * test: enable <ffi_const.lua> in LuaJIT-tests * test: enable <ffi_convert.lua> in LuaJIT-tests * test: enable <ffi_enum.lua> in LuaJIT-tests * test: enable <ffi_gcstep_recursive.lua> * test: enable <ffi_jit_arith.lua> in LuaJIT-tests * test: enable <ffi_jit_call.lua> in LuaJIT-tests * test: enable <ffi_jit_conv.lua> in LuaJIT-tests * test: enable <ffi_lex_number.lua> in LuaJIT-tests * test: enable <ffi_metatype.lua> in LuaJIT-tests * test: enable <ffi_new.lua> in LuaJIT-tests * test: enable <ffi_parse_array.lua> in LuaJIT-tests * test: enable <ffi_parse_basic.lua> in LuaJIT-tests * test: enable <ffi_parse_cdef.lua> in LuaJIT-tests * test: enable <ffi_parse_struct.lua> LuaJIT test * test: enable <ffi_tabov.lua> LuaJIT test * test: enable <lightud.lua> LuaJIT test * test: enable <api_call.lua> LuaJIT test * test: enable <catch_wrap.lua> LuaJIT test * test: enable <catch_cpp.lua> LuaJIT test * test: introduce routine to build error message * test: enable CLI-related lua-Harness tests back Closes #7834 Part of #9398 Follows up #5541 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump NO_CHANGELOG=add new tests


alter: move format compatibility check to space_check_format We assume that if the new format can store tuples matching the old format, we can update the space format without calling the engine check_format callback. This is true for both memtx and vinyl but not for memcs (EE), which doesn't support extending field types (e.g. changing int16 to int32). Let's call the engine check_format callback unconditionally and let it decide whether tuple format checking can be skipped. Needed for tarantool/tarantool-ee#694 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring


build/lua: add TEST_BUILD define/tarantool.build flag In the commit 22d507d5e968 ("iproto: don't hang on uncancellable iproto request") we used TEST_BUILD define which is absent, we only have a CMake build option with such name. Let's add a define too. While at it let's also show this flag in the `tarantool.build` table. Follow-up #8423 @TarantoolBot document Title: new tarantool.build.test_build flag It is `true` if `TEST_BUILD` build option is set and `false` otherwise.