diff --git a/.luacheckrc b/.luacheckrc
index f2573e423f..1297f415f8 100644
--- a/.luacheckrc
+++ b/.luacheckrc
@@ -3,6 +3,10 @@ std = 'luajit'
 -- This fork also introduces a new global for misc API namespace.
 read_globals = { 'misc' }
 
+max_code_line_length = 80
+max_string_line_length = 80
+max_comment_line_length = 66
+
 -- The `_TARANTOOL` global is often used for skip condition
 -- checks in tests.
 files['test/tarantool-tests/'] = {
diff --git a/test/tarantool-tests/fix-argv-handling.test.lua b/test/tarantool-tests/fix-argv-handling.test.lua
index 84b626c324..51e5436914 100644
--- a/test/tarantool-tests/fix-argv-handling.test.lua
+++ b/test/tarantool-tests/fix-argv-handling.test.lua
@@ -10,7 +10,11 @@ test:plan(1)
 -- to a single empty string if it is empty [1], so the issue is
 -- not reproducible on new kernels.
 --
+-- luacheck: push no max_comment_line_length
+--
 -- [1]: https://lore.kernel.org/all/20220201000947.2453721-1-keescook@chromium.org/
+--
+-- luacheck: pop
 
 local utils = require('utils')
 local execlib = require('execlib')
diff --git a/test/tarantool-tests/fix-binary-number-parsing.test.lua b/test/tarantool-tests/fix-binary-number-parsing.test.lua
index 9f1490820f..31358649ef 100644
--- a/test/tarantool-tests/fix-binary-number-parsing.test.lua
+++ b/test/tarantool-tests/fix-binary-number-parsing.test.lua
@@ -3,7 +3,9 @@ local tap = require('tap')
 -- Test file to demonstrate incorrect behaviour of binary number
 -- parsing with fractional dot.
 -- See also:
+-- luacheck: push no max_comment_line_length
 -- https://www.freelists.org/post/luajit/Fractional-binary-number-literals
+-- luacheck: pop
 local test = tap.test('fix-binary-number-parsing')
 test:plan(2)
 
diff --git a/test/tarantool-tests/gh-3196-incorrect-string-length.test.lua b/test/tarantool-tests/gh-3196-incorrect-string-length.test.lua
index b82029f68f..7cd71c4b91 100644
--- a/test/tarantool-tests/gh-3196-incorrect-string-length.test.lua
+++ b/test/tarantool-tests/gh-3196-incorrect-string-length.test.lua
@@ -6,10 +6,13 @@ test:plan(2)
 --
 -- gh-3196: incorrect string length if Lua hash returns 0
 --
+-- luacheck: push no max_comment_line_length
+--
 local h = "\x1F\x93\xE2\x1C\xCA\xDE\x28\x08\x26\x01\xED\x0A\x2F\xE4\x21\x02\x97\x77\xD9\x3E"
 test:is(h:len(), 20)
 
 h = "\x0F\x93\xE2\x1C\xCA\xDE\x28\x08\x26\x01\xED\x0A\x2F\xE4\x21\x02\x97\x77\xD9\x3E"
 test:is(h:len(), 20)
+-- luacheck: pop
 
 test:done(true)
diff --git a/test/tarantool-tests/gh-4773-tonumber-fail-on-NUL-char.test.lua b/test/tarantool-tests/gh-4773-tonumber-fail-on-NUL-char.test.lua
index 7bacc0f929..c3f299490c 100644
--- a/test/tarantool-tests/gh-4773-tonumber-fail-on-NUL-char.test.lua
+++ b/test/tarantool-tests/gh-4773-tonumber-fail-on-NUL-char.test.lua
@@ -3,8 +3,8 @@ local tap = require('tap')
 local test = tap.test("Tarantool 4773")
 test:plan(3)
 
--- Test file to demonstrate LuaJIT tonumber routine fails on NUL char,
--- details:
+-- Test file to demonstrate LuaJIT tonumber routine fails on NUL
+-- char, details:
 --     https://github.com/tarantool/tarantool/issues/4773
 
 local t = {
@@ -13,8 +13,9 @@ local t = {
   tail = 'imun',
 }
 
--- Since VM, Lua/C API and compiler use a single routine for conversion numeric
--- string to a number, test cases are reduced to the following:
+-- Since VM, Lua/C API and compiler use a single routine for
+-- conversion numeric string to a number, test cases are reduced
+-- to the following:
 test:is(tonumber(t.zero), 0)
 test:is(tonumber(t.zero .. t.tail), nil)
 test:is(tonumber(t.zero .. t.null .. t.tail), nil)
diff --git a/test/tarantool-tests/gh-6163-min-max.test.lua b/test/tarantool-tests/gh-6163-min-max.test.lua
index e3efd1a491..0b2680c3f7 100644
--- a/test/tarantool-tests/gh-6163-min-max.test.lua
+++ b/test/tarantool-tests/gh-6163-min-max.test.lua
@@ -45,8 +45,8 @@ jit.opt.start('hotloop=1')
 -- copy-pasted to preserve optimization semantics.
 
 -- Without the `(a o b) o a ==> a o b` fold optimization for
--- `math.min()/math.max()` the following mcode is emitted on aarch64
--- for the `math.min(math.min(x, nan), x)` expression:
+-- `math.min()/math.max()` the following mcode is emitted on
+-- aarch64 for the `math.min(math.min(x, nan), x)` expression:
 --
 -- | fcmp d2, d3 ; fcmp 1.0, nan
 -- | fcsel d1, d2, d3, cc ; d1 == nan after this instruction
@@ -54,24 +54,28 @@ jit.opt.start('hotloop=1')
 -- | fcmp d1, d2 ; fcmp nan, 1.0
 -- | fcsel d0, d1, d2, cc ; d0 == 1.0 after this instruction
 --
--- According to the `fcmp` docs[1], if either of the operands is NaN,
--- then the operands are unordered. It results in the following state
--- of the flags register: N=0, Z=0, C=1, V=1
+-- According to the `fcmp` docs[1], if either of the operands is
+-- NaN, then the operands are unordered. It results in the
+-- following state of the flags register: N=0, Z=0, C=1, V=1
 --
 -- According to the `fcsel` docs[2], if the condition is met, then
 -- the first register value is taken, otherwise -- the second.
 -- In our case, the condition is cc, which means that the `C` flag
--- should be clear[3], which is false. Then, the second value is taken,
--- which is `NaN` for the first `fcmp`-`fcsel` pair, and `1.0` for
--- the second.
+-- should be clear[3], which is false. Then, the second value is
+-- taken, which is `NaN` for the first `fcmp`-`fcsel` pair, and
+-- `1.0` for the second.
 --
--- If that fold optimization is applied, then only the first `fcmp`-`fcsel`
--- pair is emitted, and the result is `NaN`, which is inconsistent with
--- the result of the non-optimized mcode.
+-- If that fold optimization is applied, then only the first
+-- `fcmp`-`fcsel` pair is emitted, and the result is `NaN`, which
+-- is inconsistent with the result of the non-optimized mcode.
+--
+-- luacheck: push no max_comment_line_length
 --
 -- [1]: https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FCMP
 -- [2]: https://developer.arm.com/documentation/100069/0608/A64-Floating-point-Instructions/FCSEL
 -- [3]: https://developer.arm.com/documentation/dui0068/b/ARM-Instruction-Reference/Conditional-execution
+--
+-- luacheck: pop
 
 local result = {}
 for k = 1, 4 do
@@ -87,10 +91,11 @@ end
 -- expected: 1 1 1 1
 test:samevalues(result, 'math.max: reassoc_dup')
 
--- If one gets the expression like `math.min(x, math.min(x, nan))`,
--- and the `comm_dup` optimization is applied, it results in the
--- same situation as explained above. With the `comm_dup_minmax`
--- there is no swap, hence, everything is consistent again:
+-- If one gets the expression like
+-- `math.min(x, math.min(x, nan))`, and the `comm_dup`
+-- optimization is applied, it results in the same situation as
+-- explained above. With the `comm_dup_minmax` there is no swap,
+-- hence, everything is consistent again:
 --
 -- | fcmp d2, d3 ; fcmp 1.0, nan
 -- | fcsel d1, d3, d2, pl ; d1 == nan after this instruction
@@ -98,8 +103,8 @@ test:samevalues(result, 'math.max: reassoc_dup')
 -- | fcmp d2, d1 ; fcmp 1.0, nan
 -- | fcsel d0, d1, d2, pl ; d0 == nan after this instruction
 -- `pl` (aka `CC_PL`) condition means that N flag is 0 [2], that
--- is true when we are comparing something with NaN. So, the value of the
--- first source register is taken
+-- is true when we are comparing something with NaN. So, the value
+-- of the first source register is taken
 
 result = {}
 for k = 1, 4 do
@@ -193,8 +198,10 @@ end
 -- expected: nan nan nan nan
 test:samevalues(result, 'max-min-case2: reassoc_minmax_right')
 
--- XXX: If we look into the disassembled code of `lj_vm_foldarith()`
--- we can see the following:
+-- XXX: If we look into the disassembled code of
+-- `lj_vm_foldarith()` we can see the following:
+--
+-- luacheck: push no max_comment_line_length
 --
 -- | /* In our test x == 7.1, y == nan */
 -- | case IR_MIN - IR_ADD: return x > y ? y : x; break;
@@ -208,10 +215,12 @@ test:samevalues(result, 'max-min-case2: reassoc_minmax_right')
 -- | <lj_vm_foldarith+358>: mov rax,QWORD PTR [rsp+0x18] ; else return 7.1
 -- | <lj_vm_foldarith+363>: jmp <lj_vm_foldarith+398> ;
 --
--- According to `comisd` documentation [4] in case when one of the operands
--- is NaN, the result is unordered and ZF,PF,CF := 111. This means that `jbe`
--- condition is true (CF=1 or ZF=1)[5], so we return 7.1 (the first
--- operand) for case `IR_MIN`.
+-- luacheck: pop
+--
+-- According to `comisd` documentation [4] in case when one of the
+-- operands is NaN, the result is unordered and ZF,PF,CF := 111.
+-- This means that `jbe` condition is true (CF=1 or ZF=1)[5], so
+-- we return 7.1 (the first operand) for case `IR_MIN`.
 --
 -- However, in `lj_ff_math_min()` in the VM we see the following:
 -- |7:
@@ -221,7 +230,11 @@ test:samevalues(result, 'max-min-case2: reassoc_minmax_right')
 -- either a NaN or a valid floating-point value, is
 -- written to the result.
 --
--- So the patch changes the `lj_vm_foldairth()` assembly in the following way:
+-- So the patch changes the `lj_vm_foldairth()` assembly in the
+-- following way:
+--
+-- luacheck: push no max_comment_line_length
+--
 -- | ; case IR_MIN
 -- | <lj_vm_foldarith+337>: movsd xmm0,QWORD PTR [rsp+0x10] ; xmm0 <- nan
 -- | <lj_vm_foldarith+343>: comisd xmm0,QWORD PTR [rsp+0x18] ; comisd nan, 7.1
@@ -231,10 +244,13 @@ test:samevalues(result, 'max-min-case2: reassoc_minmax_right')
 -- | <lj_vm_foldarith+358>: mov rax,QWORD PTR [rsp+0x10] ; else return nan
 -- | <lj_vm_foldarith+363>: jmp <lj_vm_foldarith+398> ;
 --
+-- luacheck: pop
+--
 -- So now we always return the second operand.
 --
--- XXX: The two tests below use the `0/0` constant instead of `nan`
--- variable is dictated by the `fold_kfold_numarith` semantics.
+-- XXX: The two tests below use the `0/0` constant instead of
+-- `nan` variable is dictated by the `fold_kfold_numarith`
+-- semantics.
 result = {}
 for k = 1, 4 do
   result[k] = min(min(7.1, 0/0), 1.1)
diff --git a/test/tarantool-tests/gh-7745-oom-on-trace.test.lua b/test/tarantool-tests/gh-7745-oom-on-trace.test.lua
index 57cc663271..5d6c88fd5d 100644
--- a/test/tarantool-tests/gh-7745-oom-on-trace.test.lua
+++ b/test/tarantool-tests/gh-7745-oom-on-trace.test.lua
@@ -11,7 +11,8 @@ local test = tap.test('OOM on trace'):skipcond({
 
 test:plan(1)
 
--- NB: When GC64 is enabled, fails with TABOV, otherwise -- with OOM.
+-- NB: When GC64 is enabled, fails with TABOV, otherwise -- with
+-- OOM.
 local function memory_payload()
   local t = {} -- luacheck: no unused
   for i = 1, 1e10 do
diff --git a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
index 2ddb57658c..ed801d0dc0 100644
--- a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
+++ b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
@@ -19,9 +19,9 @@ local function eatchunks(size)
   end
 end
 
--- The chunk size below is empirical. It is big enough, so the test
--- is not too long, yet small enough for the OOM frame issue to have
--- enough iterations in the second loop to trigger.
+-- The chunk size below is empirical. It is big enough, so the
+-- test is not too long, yet small enough for the OOM frame issue
+-- to have enough iterations in the second loop to trigger.
 pcall(eatchunks, 512 * 1024 * 1024)
 
 local anchor = {}
diff --git a/test/tarantool-tests/lj-1116-redzones-checks.test.lua b/test/tarantool-tests/lj-1116-redzones-checks.test.lua
index 4f4f587033..3e6e341c32 100644
--- a/test/tarantool-tests/lj-1116-redzones-checks.test.lua
+++ b/test/tarantool-tests/lj-1116-redzones-checks.test.lua
@@ -44,7 +44,9 @@ jit.opt.start('hotloop=1')
 -- This makes this reproducer unstable (regarding the register
 -- allocator changes). So, lets use this as a regression test.
 --
+-- luacheck: push no max_comment_line_length
 -- [1]: https://wiki.osdev.org/X86-64_Instruction_Encoding#REX_prefix
+-- luacheck: pop
 
 _G.a = 0
 _G.b = 0
diff --git a/test/tarantool-tests/lj-1149-g-number-formating-bufov.test.lua b/test/tarantool-tests/lj-1149-g-number-formating-bufov.test.lua
index b10d7b2afc..3d23fc0860 100644
--- a/test/tarantool-tests/lj-1149-g-number-formating-bufov.test.lua
+++ b/test/tarantool-tests/lj-1149-g-number-formating-bufov.test.lua
@@ -11,8 +11,8 @@ test:plan(1)
 -- The number value for the test has the same precision
 -- (`prec` = 5) and amount of digits (`hilen` = 5) for the decimal
 -- representation. Hence, with `ndhi` == 0, the `ndlo` part
--- becomes 64 (the size of the `nd` stack buffer), and the overflow
--- occurs.
+-- becomes 64 (the size of the `nd` stack buffer), and the
+-- overflow occurs.
 -- See details in the <src/lj_strfmt_num.c>:`lj_strfmt_wfnum()`.
 test:is(string.format('%7g', 0x1.144399609d407p+401), '5.5733e+120',
         'correct format %7g result')
diff --git a/test/tarantool-tests/lj-366-strtab-correct-size.test.lua b/test/tarantool-tests/lj-366-strtab-correct-size.test.lua
index a20339e516..b8bd1391ae 100644
--- a/test/tarantool-tests/lj-366-strtab-correct-size.test.lua
+++ b/test/tarantool-tests/lj-366-strtab-correct-size.test.lua
@@ -14,7 +14,8 @@ local utils = require('utils')
 -- Command below exports bytecode as an object file in ELF format:
 -- $ luajit -b -n 'lango_team' -e 'print()' xxx.obj
 -- $ file xxx.obj
--- xxx.obj: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
+-- xxx.obj: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV),
+-- not stripped
 --
 -- With read_elf(1) it is possible to display entries in symbol
 -- table section of the file, if it has one. Object file contains
@@ -22,6 +23,8 @@ local utils = require('utils')
 --
 -- $ readelf --symbols xxx.obj
 --
+-- luacheck: push no max_comment_line_length
+--
 -- Symbol table '.symtab' contains 2 entries:
 --    Num:    Value          Size Type    Bind   Vis      Ndx Name
 --      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
@@ -45,6 +48,8 @@ local utils = require('utils')
 -- Reference numbers for strtab offset and size could be obtained
 -- with readelf(1). Note that number system of these numbers is
 -- hexadecimal.
+--
+-- luacheck: pop
 
 -- Symbol name prefix for LuaJIT bytecode defined in bcsave.lua.
 local LJBC_PREFIX = 'luaJIT_BC_'
@@ -139,11 +144,12 @@ local function create_obj_file(name)
   return elf_filename
 end
 
--- Parses a buffer in an ELF format and returns an offset and a size of strtab
--- and symtab sections.
+-- Parses a buffer in an ELF format and returns an offset and a
+-- size of strtab and symtab sections.
 local function read_elf(elf_content)
   local ELFobj_type = ffi.typeof(is64 and 'ELF64obj *' or 'ELF32obj *')
-  local ELFsectheader_type = ffi.typeof(is64 and 'ELF64sectheader *' or 'ELF32sectheader *')
+  local ELFsectheader_type = ffi.typeof(is64 and 'ELF64sectheader *' or
+                                        'ELF32sectheader *')
   local elf = ffi.cast(ELFobj_type, elf_content)
   local symtab_hdr, strtab_hdr
   -- Iterate by section headers.
@@ -178,7 +184,8 @@ assert(sym_cnt ~= 0, 'number of symbols is zero')
 test:is(strtab_size, EXPECTED_STRTAB_SIZE, 'check .strtab size')
 test:is(strtab_offset, EXPECTED_STRTAB_OFFSET, 'check .strtab offset')
 
-local strtab_str = string.sub(elf_content, strtab_offset, strtab_offset + strtab_size)
+local strtab_str = string.sub(elf_content, strtab_offset,
+                              strtab_offset + strtab_size)
 
 local strtab_p = ffi.cast('char *', strtab_str)
 local sym_is_found = false
diff --git a/test/tarantool-tests/lj-416-xor-before-jcc.test.lua b/test/tarantool-tests/lj-416-xor-before-jcc.test.lua
index f71c9ee467..cf8cb58c53 100644
--- a/test/tarantool-tests/lj-416-xor-before-jcc.test.lua
+++ b/test/tarantool-tests/lj-416-xor-before-jcc.test.lua
@@ -6,20 +6,22 @@ local test = tap.test('lj-416-xor-before-jcc'):skipcond({
 test:plan(1)
 
 -- To reproduce this issue, we need:
--- 0) IR for either "internal" (e.g. type check, hmask check) or "external"
---    (e.g. branch or loop condition) guard begins to be emitted to
---    mcode.
--- 1) JCC to side exit is emitted to the trace mcode at the beginning.
+-- 0) IR for either "internal" (e.g. type check, hmask check) or
+--    "external" (e.g. branch or loop condition) guard begins to
+--    be emitted to mcode.
+-- 1) JCC to side exit is emitted to the trace mcode at the
+--    beginning.
 -- 2) Condition (i.e. comparison) is going to be emitted.
--- 3) Fuse optimization takes its place, that ought to allocate a register
---    for the load base.
+-- 3) Fuse optimization takes its place, that ought to allocate a
+--    register for the load base.
 -- 4) There are no free registers at this point.
--- 5) The one storing the constant zero is chosen to be sacrificed and
---    reallocated (consider the allocation cost in ra_alloc for constant
---    materialization).
--- 6) Before (or in the sense of trace execution, after) register is
---    being used in the aforementioned comparison, register (r14 in our
---    case) is reset by XOR emitted right after (before) jump instruction.
+-- 5) The one storing the constant zero is chosen to be sacrificed
+--    and reallocated (consider the allocation cost in ra_alloc
+--    for constant materialization).
+-- 6) Before (or in the sense of trace execution, after) register
+--    is being used in the aforementioned comparison, register
+--    (r14 in our case) is reset by XOR emitted right after
+--    (before) jump instruction.
 -- 7) The comparison with fused load within is emitted.
 --
 -- This leads to assembly code like the following:
@@ -69,6 +71,7 @@ local function testf()
     end
   end
 
+  -- luacheck: push no max_comment_line_length
   -- The code below is recorded with the following IRs:
   -- ....              SNAP   #1   [ lj-416-xor-before-jcc.test.lua:44|---- ]
   -- 0012       >  num UGT    0009  +42
@@ -80,6 +83,7 @@ local function testf()
   --
   -- As a result, this branch is taken due to the emitted `xor`
   -- instruction until the issue is not resolved.
+  -- luacheck: pop
   if value <= MAGIC then
     return true
   end
diff --git a/test/tarantool-tests/lj-494-table-chain-infinite-loop.test.lua b/test/tarantool-tests/lj-494-table-chain-infinite-loop.test.lua
index 3dd17e7ada..b7b6546dc8 100644
--- a/test/tarantool-tests/lj-494-table-chain-infinite-loop.test.lua
+++ b/test/tarantool-tests/lj-494-table-chain-infinite-loop.test.lua
@@ -6,7 +6,7 @@ test:plan(1)
 -- Test file to demonstrate Lua table hash chain bugs discussed in
 --     https://github.com/LuaJIT/LuaJIT/issues/494
 -- Credit: prepared by Peter Cawley here with minor edits:
---     https://gist.github.com/corsix/1fc9b13a2dd5f3659417b62dd54d4500
+-- https://gist.github.com/corsix/1fc9b13a2dd5f3659417b62dd54d4500
 
 --- Plumbing
 local ffi = require("ffi")
@@ -93,7 +93,8 @@ do --- Just `mn != nn` can lead to infinite loops
     t[victims.d] = true
     t[victims.c] = true
     t[victims.b] = true
-    -- Change c's primary to b, d's primary to d, and e's primary to d
+    -- Change c's primary to b, d's primary to d, and e's primary
+    -- to d
     t[victims.e] = nil
     t[victims.d] = nil
     t[victims.c] = nil
@@ -103,7 +104,8 @@ do --- Just `mn != nn` can lead to infinite loops
     t[victims.c] = true
     t[victims.d] = true
     t[victims.e] = true
-    -- Insert something with b as primary (infinite rechaining loop)
+    -- Insert something with b as primary (infinite rechaining
+    -- loop)
     str_hash(victims.f)[0] = 4
     t[victims.f] = true
 end
@@ -163,7 +165,8 @@ do --- Do not forget to advance freenode in the not-string case
     t[0x0p-1074] = true
     t[0x4p-1074] = true
     t[0x8p-1074] = true
-    -- Steal middle node of the chain to be a main node (infinite walking loop)
+    -- Steal middle node of the chain to be a main node (infinite
+    -- walking loop)
     t[0x2p-1074] = true
 end
 collectgarbage()
@@ -172,6 +175,7 @@ collectgarbage()
 for c, v in pairs(victims) do
     str_hash(v)[0] = orig_hash[c]
 end
-test:ok(true, "table keys collisions are resolved properly (no assertions failed)")
+test:ok(true,
+        "table keys collisions are resolved properly (no assertions failed)")
 
 test:done(true)
diff --git a/test/tarantool-tests/lj-505-fold-no-strref-for-ptrdiff.test.lua b/test/tarantool-tests/lj-505-fold-no-strref-for-ptrdiff.test.lua
index a40e779654..eabc045b3a 100644
--- a/test/tarantool-tests/lj-505-fold-no-strref-for-ptrdiff.test.lua
+++ b/test/tarantool-tests/lj-505-fold-no-strref-for-ptrdiff.test.lua
@@ -5,7 +5,8 @@ local test = tap.test("lj-505-fold-icorrect-behavior"):skipcond({
 
 test:plan(1)
 
--- Test file to demonstrate Lua fold machinery icorrect behavior, details:
+-- Test file to demonstrate Lua fold machinery icorrect behavior,
+-- details:
 --     https://github.com/LuaJIT/LuaJIT/issues/505
 
 jit.opt.start("hotloop=1")
diff --git a/test/tarantool-tests/lj-524-fold-conv-respect-src-irt.test.lua b/test/tarantool-tests/lj-524-fold-conv-respect-src-irt.test.lua
index 70d330ac09..5bb0a90677 100644
--- a/test/tarantool-tests/lj-524-fold-conv-respect-src-irt.test.lua
+++ b/test/tarantool-tests/lj-524-fold-conv-respect-src-irt.test.lua
@@ -6,8 +6,8 @@ local test = tap.test('or-524-fold-icorrect-behavior'):skipcond({
 test:plan(1)
 
 local ffi = require('ffi')
--- Test file to demonstrate LuaJIT folding machinery incorrect behaviour,
--- details:
+-- Test file to demonstrate LuaJIT folding machinery incorrect
+-- behaviour, details:
 --     https://github.com/LuaJIT/LuaJIT/issues/524
 --     https://github.com/moonjit/moonjit/issues/37
 
diff --git a/test/tarantool-tests/lj-603-err-snap-restore.test.lua b/test/tarantool-tests/lj-603-err-snap-restore.test.lua
index d11d474ed3..e52f0ec77e 100644
--- a/test/tarantool-tests/lj-603-err-snap-restore.test.lua
+++ b/test/tarantool-tests/lj-603-err-snap-restore.test.lua
@@ -11,9 +11,9 @@ local function do_test()
   local recursive_f
   local function errfunc()
     xpcall(recursive_f, errfunc)
-    -- Since this error is occurred on snapshot restoration and can
-    -- be handled by compiler itself, we shouldn't bother a user
-    -- with it.
+    -- Since this error is occurred on snapshot restoration and
+    -- can be handled by compiler itself, we shouldn't bother a
+    -- user with it.
     handler_is_called = true
   end
 
diff --git a/test/tarantool-tests/lj-611-gc64-inherit-frame-slot-orig.test.lua b/test/tarantool-tests/lj-611-gc64-inherit-frame-slot-orig.test.lua
index 6308f2eaf7..5f39a87089 100644
--- a/test/tarantool-tests/lj-611-gc64-inherit-frame-slot-orig.test.lua
+++ b/test/tarantool-tests/lj-611-gc64-inherit-frame-slot-orig.test.lua
@@ -11,8 +11,10 @@ jit.opt.start('hotloop=1', 'hotexit=1')
 -- for non-base frame" [1], and is based on the reproducer
 -- described in [2].
 --
+-- luacheck: push no max_comment_line_length
 -- [1]: https://github.com/LuaJIT/LuaJIT/issues/611
 -- [2]: https://github.com/LuaJIT/LuaJIT/issues/611#issuecomment-679228156
+-- luacheck: pop
 --
 -- Function `outer` is recorded to a trace and calls a built-in
 -- function that is not JIT-compilable and therefore triggers
diff --git a/test/tarantool-tests/lj-611-gc64-inherit-frame-slot.test.lua b/test/tarantool-tests/lj-611-gc64-inherit-frame-slot.test.lua
index b7347267b1..a5a2d23fbb 100644
--- a/test/tarantool-tests/lj-611-gc64-inherit-frame-slot.test.lua
+++ b/test/tarantool-tests/lj-611-gc64-inherit-frame-slot.test.lua
@@ -35,7 +35,9 @@ end
 -- objects from the prototype of the `inner()` function and hit
 -- the `PROTO_CLC_POLY` limit, so the side traces stop spawning.
 -- See also:
+-- luacheck: push no max_comment_line_length
 -- https://github.com/tarantool/tarantool/wiki/LuaJIT-function-inlining.
+-- luacheck: pop
 lower_frame()
 lower_frame()
 -- Compile hotexit.
diff --git a/test/tarantool-tests/lj-624-jloop-snapshot-pc.test.lua b/test/tarantool-tests/lj-624-jloop-snapshot-pc.test.lua
index 565e4cbfdf..6900f0ab34 100644
--- a/test/tarantool-tests/lj-624-jloop-snapshot-pc.test.lua
+++ b/test/tarantool-tests/lj-624-jloop-snapshot-pc.test.lua
@@ -66,8 +66,8 @@ test:plan(1)
 -- 0012  ADDVV    1   1   2
 -- 0013  JLOOP    3   3
 --
--- The assertion introduced in the previous patch is triggered during
--- recording of the last 0013 JLOOP.
+-- The assertion introduced in the previous patch is triggered
+-- during recording of the last 0013 JLOOP.
 --
 -- See also:
 -- https://github.com/luaJIT/LuaJIT/issues/624
diff --git a/test/tarantool-tests/lj-688-snap-ir-rename.test.lua b/test/tarantool-tests/lj-688-snap-ir-rename.test.lua
index 807e081123..383eb0a562 100644
--- a/test/tarantool-tests/lj-688-snap-ir-rename.test.lua
+++ b/test/tarantool-tests/lj-688-snap-ir-rename.test.lua
@@ -41,7 +41,9 @@ jit.opt.start('hotloop=1')
 -- platform-agnostic, there is no real necessity to test it
 -- against ARM/ARM64 separately.
 --
+-- luacheck: push no max_comment_line_length
 -- See also https://drive.google.com/file/d/1iYkFx3F0DOtB9o9ykWfCEm-OdlJNCCL0/view?usp=share_link
+-- luacheck: pop
 
 
 local vals = {-0.1, 0.1, -0.1, 0.1}
diff --git a/test/tarantool-tests/lj-737-snap-use-def-upvalues.test.lua b/test/tarantool-tests/lj-737-snap-use-def-upvalues.test.lua
index 8535f9f69e..6bcb13d0bd 100644
--- a/test/tarantool-tests/lj-737-snap-use-def-upvalues.test.lua
+++ b/test/tarantool-tests/lj-737-snap-use-def-upvalues.test.lua
@@ -27,7 +27,8 @@ local function wrapped_trace(create_closure)
     if i == 2 then
       -- Before the patch, this slot was considered unused by
       -- use-def analysis in the `snap_usedef()` since there are
-      -- no open unpvalues for `closure()` on recording (1st call).
+      -- no open unpvalues for `closure()` on recording
+      -- (1st call).
       local_upvalue = EXPECTED
       -- luacheck: ignore
       -- Emit an additional snapshot after setting the
diff --git a/test/tarantool-tests/lj-819-fix-missing-uclo.test.lua b/test/tarantool-tests/lj-819-fix-missing-uclo.test.lua
index e2352c9296..c18c3b6e4c 100644
--- a/test/tarantool-tests/lj-819-fix-missing-uclo.test.lua
+++ b/test/tarantool-tests/lj-819-fix-missing-uclo.test.lua
@@ -1,27 +1,30 @@
 local tap = require('tap')
--- Test contains a reproducer for a problem when LuaJIT generates a wrong
--- bytecode with a missed BC_UCLO instruction.
+-- Test contains a reproducer for a problem when LuaJIT generates
+-- a wrong bytecode with a missed BC_UCLO instruction.
 local test = tap.test('lj-819-fix-missing-uclo'):skipcond({
   ['Test requires JIT enabled'] = not jit.status(),
 })
 
 test:plan(2)
 
--- Let's take a look at listings Listing 1 and Listing 2 below with bytecode
--- generated for a function missing_uclo() with and without a patch.
+-- Let's take a look at listings Listing 1 and Listing 2 below
+-- with bytecode generated for a function missing_uclo() with and
+-- without a patch.
 -- Both listings contains two BC_UCLO instructions:
--- - first one with id 0004 is generated for a statement 'break' inside
---   condition, see label BC_UCLO1;
--- - second one with id 0009 is generated for a statement 'return' inside
---   a nested loop, see label BC_UCLO2;
--- Both BC_UCLO's closes upvalues after leaving a function's scope.
+-- - first one with id 0004 is generated for a statement 'break'
+--   inside condition, see label BC_UCLO1;
+-- - second one with id 0009 is generated for a statement 'return'
+--   inside a nested loop, see label BC_UCLO2;
+-- Both BC_UCLO's closes upvalues after leaving a function's
+-- scope.
 --
--- The problem is happen when fs_fixup_ret() traverses bytecode instructions in
--- a function prototype, meets first BC_UCLO instruction (break) and forgives a
--- second one (return). This leads to a wrong result produced by a function
--- returned by missing_uclo() function. This also explains why do we need a
--- dead code in reproducer - without first BC_UCLO fs_fixup_ret() successfully
--- fixup BC_UCLO and problem does not appear.
+-- The problem is happen when fs_fixup_ret() traverses bytecode
+-- instructions in a function prototype, meets first BC_UCLO
+-- instruction (break) and forgives a second one (return). This
+-- leads to a wrong result produced by a function returned by
+-- missing_uclo() function. This also explains why do we need a
+-- dead code in reproducer - without first BC_UCLO fs_fixup_ret()
+-- successfully fixup BC_UCLO and problem does not appear.
 --
 -- Listing 1. Bytecode with a fix.
 --
@@ -74,11 +77,13 @@ test:plan(2)
 -- +0014 => RET1     0   2
 --
 -- First testcase checks a correct bytecode generation by frontend
--- and the second testcase checks consistency on a JIT compilation.
+-- and the second testcase checks consistency on a JIT
+-- compilation.
 
 local function missing_uclo()
   while true do -- luacheck: ignore
-    -- Attention: it is not a dead code, it is a part of reproducer.
+    -- Attention: it is not a dead code, it is a part of
+    -- reproducer.
     -- label: BC_UCLO1
     if false then
       break
@@ -98,9 +103,10 @@ end
 
 local f = missing_uclo()
 local res = f()
--- Without a patch we don't get here a function, because upvalue isn't closed
--- as desirable.
-test:ok(type(res) == 'function', 'virtual machine consistency: type of returned value is correct')
+-- Without a patch we don't get here a function, because upvalue
+-- isn't closed as desirable.
+test:ok(type(res) == 'function',
+        'virtual machine consistency: type of returned value is correct')
 
 -- Make JIT compiler aggressive.
 jit.opt.start('hotloop=1')
@@ -110,6 +116,7 @@ f()
 f = missing_uclo()
 local _
 _, res = pcall(f)
-test:ok(type(res) == 'function', 'consistency on compilation: type of returned value is correct')
+test:ok(type(res) == 'function',
+        'consistency on compilation: type of returned value is correct')
 
 test:done(true)
diff --git a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua
index 4d0767330e..45496bf4d1 100644
--- a/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua
+++ b/test/tarantool-tests/lj-865-cross-generation-mach-o-file.test.lua
@@ -22,6 +22,8 @@ local ffi = require('ffi')
 --
 -- Manual steps for reproducing are the following:
 --
+-- luacheck: push no max_comment_line_length
+--
 -- $ CC=gcc TARGET_CFLAGS='skylake-avx512' cmake -S . -B build
 -- $ cmake --build build --parallel
 -- $ echo > test.lua
@@ -59,6 +61,8 @@ local ffi = require('ffi')
 -- 1. https://github.com/aidansteele/osx-abi-macho-file-format-reference
 -- 2. https://reverseengineering.stackexchange.com/a/6357/46029
 -- 3. http://formats.kaitai.io/mach_o/index.html
+--
+-- luacheck: pop
 
 test:plan(1)
 
diff --git a/test/tarantool-tests/lj-918-fma-numerical-accuracy-jit.test.lua b/test/tarantool-tests/lj-918-fma-numerical-accuracy-jit.test.lua
index 8b16d4c3e7..0acda2a00b 100644
--- a/test/tarantool-tests/lj-918-fma-numerical-accuracy-jit.test.lua
+++ b/test/tarantool-tests/lj-918-fma-numerical-accuracy-jit.test.lua
@@ -22,9 +22,13 @@ local _2pow52 = 2 ^ 52
 -- double rounding. The numbers from the original issue are good
 -- enough.
 --
+-- luacheck: push no max_comment_line_length
+--
 -- [1]:https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FMSUB
 -- [2]:https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation
 --
+-- luacheck: pop
+--
 -- IEEE754 components to double:
 -- sign * (2 ^ (exp - 1023)) * (mantissa / _2pow52 + normal).
 local a = 1 * (2 ^ (1083 - 1023)) * (4080546448249347 / _2pow52 + 1)
diff --git a/test/tarantool-tests/lj-918-fma-numerical-accuracy.test.lua b/test/tarantool-tests/lj-918-fma-numerical-accuracy.test.lua
index 25b5970756..103646fa6f 100644
--- a/test/tarantool-tests/lj-918-fma-numerical-accuracy.test.lua
+++ b/test/tarantool-tests/lj-918-fma-numerical-accuracy.test.lua
@@ -20,9 +20,13 @@ local _2pow52 = 2 ^ 52
 -- double rounding. The numbers from the original issue are good
 -- enough.
 --
+-- luacheck: push no max_comment_line_length
+--
 -- [1]:https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FMSUB
 -- [2]:https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation
 --
+-- luacheck: pop
+--
 -- IEEE754 components to double:
 -- sign * (2 ^ (exp - 1023)) * (mantissa / _2pow52 + normal).
 local a = 1 * (2 ^ (1083 - 1023)) * (4080546448249347 / _2pow52 + 1)
diff --git a/test/tarantool-tests/lj-962-stack-overflow-report.test.lua b/test/tarantool-tests/lj-962-stack-overflow-report.test.lua
index 45a888f454..848f4eada8 100644
--- a/test/tarantool-tests/lj-962-stack-overflow-report.test.lua
+++ b/test/tarantool-tests/lj-962-stack-overflow-report.test.lua
@@ -1,5 +1,6 @@
 local tap = require('tap')
--- The test reproduces the problem only for GC64 mode with enabled JIT.
+-- The test reproduces the problem only for GC64 mode with enabled
+-- JIT.
 local test = tap.test('lj-962-stack-overflow-report')
 test:plan(1)
 
diff --git a/test/tarantool-tests/lj-962-stack-overflow-report/script.lua b/test/tarantool-tests/lj-962-stack-overflow-report/script.lua
index 31c5ca338b..fca952dc69 100644
--- a/test/tarantool-tests/lj-962-stack-overflow-report/script.lua
+++ b/test/tarantool-tests/lj-962-stack-overflow-report/script.lua
@@ -1,3 +1,4 @@
--- XXX: Function `f` is global to avoid using an additional stack slot.
+-- XXX: Function `f` is global to avoid using an additional stack
+-- slot.
 -- luacheck: no global
 f = function() f() end; f()
diff --git a/test/tarantool-tests/mark-conv-non-weak.test.lua b/test/tarantool-tests/mark-conv-non-weak.test.lua
index 73c24b6635..fe0969cff0 100644
--- a/test/tarantool-tests/mark-conv-non-weak.test.lua
+++ b/test/tarantool-tests/mark-conv-non-weak.test.lua
@@ -4,6 +4,7 @@ local test = tap.test('mark-conv-non-weak'):skipcond({
 })
 
 test:plan(1)
+-- luacheck: push no max_comment_line_length
 -- XXX: These values were chosen to create type instability
 -- in the loop-carried dependency, so the checked `CONV int.num`
 -- instruction is emitted. See `loop_unrool` in `lj_opt_loop.c`.
@@ -114,6 +115,7 @@ jit.opt.start('hotloop=1')
 --
 -- Note that DCE happens on the assembly part of the trace
 -- compilation. That is why `CONV` is present in both IRs.
+-- luacheck: pop
 
 for _, val in ipairs(data) do
     if val == val then
diff --git a/test/tarantool-tests/misclib-getmetrics-lapi.test.lua b/test/tarantool-tests/misclib-getmetrics-lapi.test.lua
index 89aecf7bf2..818c0294b0 100644
--- a/test/tarantool-tests/misclib-getmetrics-lapi.test.lua
+++ b/test/tarantool-tests/misclib-getmetrics-lapi.test.lua
@@ -1,5 +1,6 @@
 -- This is a part of tarantool/luajit testing suite.
--- Major portions taken verbatim or adapted from the LuaVela testing suite.
+-- Major portions taken verbatim or adapted from the LuaVela
+-- testing suite.
 -- Copyright (C) 2015-2019 IPONWEB Ltd.
 
 local tap = require('tap')
@@ -77,7 +78,8 @@ test:test("gc-allocated-freed", function(subtest)
     -- (such as concatenation, string.format, table.concat)
     -- while creating the string. Otherwise gc_freed/gc_allocated
     -- relations will not be so straightforward.
-    local str = string.sub("Hello, world", 1, 5) -- luacheck: no unused
+    -- luacheck: no unused
+    local str = string.sub("Hello, world", 1, 5)
     collectgarbage("collect")
 
     new_metrics = misc.getmetrics()
@@ -333,7 +335,8 @@ test:test("snap-restores-loop-side-exit", function(subtest)
 end)
 
 test:test("snap-restores-scalar", function(subtest)
-    -- Compiled scalar trace with a direct exit to the interpreter.
+    -- Compiled scalar trace with a direct exit to the
+    -- interpreter.
     subtest:plan(2)
 
     -- For calls it will be 2 * hotloop (see lj_dispatch.{c,h}
diff --git a/test/tarantool-tests/or-144-gc64-asmref-l.test.lua b/test/tarantool-tests/or-144-gc64-asmref-l.test.lua
index 18c6efb203..e674de1a05 100644
--- a/test/tarantool-tests/or-144-gc64-asmref-l.test.lua
+++ b/test/tarantool-tests/or-144-gc64-asmref-l.test.lua
@@ -5,11 +5,15 @@ local test = tap.test('or-144-gc64-asmref-l'):skipcond({
 
 test:plan(1)
 
+-- luacheck: push no max_comment_line_length
+--
 -- Test file to demonstrate LuaJIT `IR_LREF` assembling incorrect
 -- behaviour.
 -- See also:
 -- * https://github.com/openresty/lua-resty-core/issues/144.
 -- * https://www.freelists.org/post/luajit/Consistent-SEGV-on-x64-with-the-latest-LuaJIT-v21-GC64-mode.
+--
+-- luacheck: pop
 
 jit.opt.start('hotloop=1')
 
diff --git a/test/tarantool-tests/or-232-unsink-64-kptr.test.lua b/test/tarantool-tests/or-232-unsink-64-kptr.test.lua
index 4a0ece896e..55d2a8e045 100644
--- a/test/tarantool-tests/or-232-unsink-64-kptr.test.lua
+++ b/test/tarantool-tests/or-232-unsink-64-kptr.test.lua
@@ -4,7 +4,8 @@ local test = tap.test("or-232-unsink-64-kptr")
 test:plan(1)
 
 --- From: Thibault Charbonnier <thibaultcha@me.com>
---- tests: ffi: added a test case unsinking a 64-bit pointer from a constant.
+--- tests: ffi: added a test case unsinking a 64-bit pointer from
+--- a constant.
 ---
 --- This test case reproduces the issue observed at:
 --- https://github.com/openresty/lua-resty-core/issues/232 and was
@@ -16,22 +17,25 @@ local ffi = require("ffi")
 
 local array = ffi.new("struct { int x; } [1]")
 
--- This test forces the VM to unsink a pointer that was constructed
--- from a constant. The IR will include a 'cnewi' instruction to
--- allocate an FFI pointer object, the pointer value will be an IR
--- constant, the allocation will be sunk, and the allocation will
--- at some point be "unsunk" due to a reference in the snapshot for
--- a taken exit.
+-- This test forces the VM to unsink a pointer that was
+-- constructed from a constant. The IR will include a 'cnewi'
+-- instruction to allocate an FFI pointer object, the pointer
+-- value will be an IR constant, the allocation will be sunk, and
+-- the allocation will at some point be "unsunk" due to a
+-- reference in the snapshot for a taken exit.
 
 -- Note: JIT will recognize <array> as a "singleton" and allow its
 -- address to be inlined ("constified") instead of looking up the
 -- upvalue at runtime.
 
 local function fn(i)
-    local struct = array[0]     -- Load pointer that the JIT will constify.
+    -- Load pointer that the JIT will constify.
+    local struct = array[0]
+    -- Force trace exit when i==1000.
     -- luacheck: ignore
-    if i == 1000 then end       -- Force trace exit when i==1000.
-    struct.x = 0                -- Ensure that 'struct' is live after exit.
+    if i == 1000 then end
+    -- Ensure that 'struct' is live after exit.
+    struct.x = 0
 end
 
 -- Loop over the function to make it compile and take a trace exit
diff --git a/test/tarantool-tests/profilers/gh-5688-tool-cli-flag.test.lua b/test/tarantool-tests/profilers/gh-5688-tool-cli-flag.test.lua
index 7704b56fe4..f47bf5302d 100644
--- a/test/tarantool-tests/profilers/gh-5688-tool-cli-flag.test.lua
+++ b/test/tarantool-tests/profilers/gh-5688-tool-cli-flag.test.lua
@@ -3,7 +3,8 @@ local test = tap.test('gh-5688-tool-cli-flag'):skipcond({
   ['Profile tools are implemented for x86_64 only'] = jit.arch ~= 'x86' and
                                                       jit.arch ~= 'x64',
   ['Profile tools are implemented for Linux only'] = jit.os ~= 'Linux',
-  -- XXX: Tarantool integration is required to run this test properly.
+  -- XXX: Tarantool integration is required to run this test
+  -- properly.
   ['No profile tools CLI option integration'] = _TARANTOOL,
   -- See also https://github.com/LuaJIT/LuaJIT/issues/606.
   ['Disabled due to LuaJIT/LuaJIT#606'] = os.getenv('LUAJIT_TABLE_BUMP'),
diff --git a/test/tarantool-tests/profilers/gh-5813-resolving-of-c-symbols.test.lua b/test/tarantool-tests/profilers/gh-5813-resolving-of-c-symbols.test.lua
index 4af1cf794a..ce36174879 100644
--- a/test/tarantool-tests/profilers/gh-5813-resolving-of-c-symbols.test.lua
+++ b/test/tarantool-tests/profilers/gh-5813-resolving-of-c-symbols.test.lua
@@ -90,9 +90,10 @@ test:ok(tree_contains(symbols.cfunc, "allocate_string"))
 symbols = generate_parsed_symtab(testboth.allocate_string)
 test:ok(tree_contains(symbols.cfunc, "allocate_string"))
 
--- FIXME: There is one case that is not tested -- shared objects, which
--- have neither .symtab section nor .dynsym segment. It is unclear how to
--- perform a test in that case, since it is impossible to load Lua module
--- written in C if it doesn't have a .dynsym segment.
+-- FIXME: There is one case that is not tested -- shared objects,
+-- which have neither .symtab section nor .dynsym segment. It is
+-- unclear how to perform a test in that case, since it is
+-- impossible to load Lua module written in C if it doesn't have
+-- a .dynsym segment.
 
 test:done(true)
diff --git a/test/tarantool-tests/profilers/gh-5994-memprof-human-readable.test.lua b/test/tarantool-tests/profilers/gh-5994-memprof-human-readable.test.lua
index f304177921..396e5a13a6 100644
--- a/test/tarantool-tests/profilers/gh-5994-memprof-human-readable.test.lua
+++ b/test/tarantool-tests/profilers/gh-5994-memprof-human-readable.test.lua
@@ -3,7 +3,8 @@ local test = tap.test('gh-5994-memprof-human-readable'):skipcond({
   ['Profile tools are implemented for x86_64 only'] = jit.arch ~= 'x86' and
                                                       jit.arch ~= 'x64',
   ['Profile tools are implemented for Linux only'] = jit.os ~= 'Linux',
-  -- XXX: Tarantool integration is required to run this test properly.
+  -- XXX: Tarantool integration is required to run this test
+  -- properly.
   ['No profile tools CLI option integration'] = _TARANTOOL,
   -- See also https://github.com/LuaJIT/LuaJIT/issues/606.
   ['Disabled due to LuaJIT/LuaJIT#606'] = os.getenv('LUAJIT_TABLE_BUMP'),
diff --git a/test/tarantool-tests/profilers/gh-9217-profile-parsers-error-handling.test.lua b/test/tarantool-tests/profilers/gh-9217-profile-parsers-error-handling.test.lua
index 68c1b72644..05a6c207f3 100644
--- a/test/tarantool-tests/profilers/gh-9217-profile-parsers-error-handling.test.lua
+++ b/test/tarantool-tests/profilers/gh-9217-profile-parsers-error-handling.test.lua
@@ -3,7 +3,8 @@ local test = tap.test('gh-9217-profile-parsers-error-handling'):skipcond({
   ['Profile tools are implemented for x86_64 only'] = jit.arch ~= 'x86' and
                                                       jit.arch ~= 'x64',
   ['Profile tools are implemented for Linux only'] = jit.os ~= 'Linux',
-  -- XXX: Tarantool integration is required to run this test properly.
+  -- XXX: Tarantool integration is required to run this test
+  -- properly.
   ['No profile tools CLI option integration'] = _TARANTOOL,
   -- See also https://github.com/LuaJIT/LuaJIT/issues/606.
   ['Disabled due to LuaJIT/LuaJIT#606'] = os.getenv('LUAJIT_TABLE_BUMP'),