[Tarantool-patches] [PATCH luajit 2/3] test: adapt PUC-Rio Lua 5.1 test suite for LuaJIT
Sergey Kaplun
skaplun at tarantool.org
Fri Mar 26 11:26:16 MSK 2021
Igor,
Thanks for the review!
On 22.03.21, Igor Munkin wrote:
> Sergey,
>
> Thanks for the patch! It's so sad that you ignored the path and approach
> for adopting test suites we have discussed so much. You've squashed all
> changes into one. For what? To save SHA1 hashes? To write less commit
> messages? But it simply makes my job harder. I haven't checked the
> changes below (yet), since I need to revert them manually one by one.
> The wording is not clear in some places. This is simply a mess. Please
> split the changes, otherwise it's too hard to review them now and
> maintain them later.
This was discussed with you offline and you asked about it personally.
I don't understand why do you blame me in this situation -- you've taken
a part in this decision too. I don't try to make your job harder, just
follow our previous agreements.
OK, I've resent the series [1] with separated commits as you want it now.
>
> As a result, I only glanced the changes: there are some unnecessary,
> since you can simply fix the issue in a standalone commit, there are
I didn't done it before only because you asked me not to do that, but
only commented these tests (even obvious cases) and create corresponding
issue if we want to fix them. I'll uncomment and fix obvious tests.
> several with unclear reasoning (so nobody except you can fix it for a
> couple of hours). There is even not a keyword to find the tests you
> commented (but I remember we agreed to use one, e.g. FIXME).
Yes, we came to agreement discuss that on review. Let's use FIXME for
test to adjust and LuaJIT for fixed tests.
>
> See other comments inline.
>
> On 12.03.21, Sergey Kaplun wrote:
> > In some insignificant details LuaJIT's behaviour is not the same
> > as the behaviour of Lua 5.1.
> >
> > Tests in the following files are disabled with corresponding comments:
> > * closure.lua
> > * constructs.lua
> > * db.lua
> > * errors.lua
> > * literals.lua
> > * main.lua
> > * math.lua
> > * nextvar.lua
> > * pm.lua
> > * strings.lua
> > * vararg.lua
> >
> > See full list of disabled tests to adapt in
> > https://github.com/tarantool/tarantool/issues/5870.
> >
> > jit.off() as prologue and jit.on() as epilogue is added to one test
> > chunk in gc.lua for stable (JIT unrelated) GC test results.
> >
> > Part of tarantool/tarantool#5845
> > Part of tarantool/tarantool#4473
> > ---
> > test/PUC-Lua-5.1-tests/closure.lua | 12 ++++-
> > test/PUC-Lua-5.1-tests/constructs.lua | 7 +++
> > test/PUC-Lua-5.1-tests/db.lua | 75 ++++++++++++++++++++-------
> > test/PUC-Lua-5.1-tests/errors.lua | 28 +++++++---
> > test/PUC-Lua-5.1-tests/gc.lua | 5 ++
> > test/PUC-Lua-5.1-tests/literals.lua | 5 ++
> > test/PUC-Lua-5.1-tests/main.lua | 56 ++++++++++++++------
> > test/PUC-Lua-5.1-tests/math.lua | 7 ++-
> > test/PUC-Lua-5.1-tests/nextvar.lua | 7 +++
> > test/PUC-Lua-5.1-tests/pm.lua | 6 ++-
> > test/PUC-Lua-5.1-tests/strings.lua | 17 +++++-
> > test/PUC-Lua-5.1-tests/vararg.lua | 20 ++++---
> > 12 files changed, 195 insertions(+), 50 deletions(-)
> >
> > diff --git a/test/PUC-Lua-5.1-tests/closure.lua b/test/PUC-Lua-5.1-tests/closure.lua
> > index 27ca0ad..e9bd564 100644
> > --- a/test/PUC-Lua-5.1-tests/closure.lua
> > +++ b/test/PUC-Lua-5.1-tests/closure.lua
> > @@ -174,7 +174,10 @@ f = coroutine.wrap(foo)
> > local a = {}
> > assert(f(a) == _G)
> > local a,b = pcall(f)
> > -assert(a and b == _G)
> > +-- LuaJIT getfenv() behaviour is different in tail calls.
> > +-- See also https://github.com/tarantool/tarantool/issues/5713.
>
> OK, the behaviour is different... So what? To understand what is
> different, one need to uncomment the line below and make another
> investigation for the issue. But you've already done one... There is not
> a word regarding what is broken and what is the difference between Lua
> and LuaJIT. Only the recipe, you need to implement for 2.10.1.
>
> Please, clarify the root problem you faced, considering anyone except
> you can take this issue and fix it.
Reworded in the new version.
>
> > +-- Test is disabled for LuaJIT for now.
> > +-- assert(a and b == _G)
> >
> >
> > -- tests for multiple yield/resume arguments
> > @@ -261,6 +264,12 @@ end
> >
> > local x = gen(100)
> > local a = {}
> > +-- In Lua 5.1 math.mod() is renamed to math.fmod() if build
> > +-- Lua 5.1 without flag `-DLUA_COMPAT_MOD`.
> > +-- LuaJIT also has math.fmod() instead math.mod() builtin.
> > +-- See also https://github.com/tarantool/tarantool/issues/5711.
>
> I believe, you can s/math.mod/math.fmod/ within this series and resolve
> the mentioned issue. The problem is trivial and the fix is quite simple.
Done in the new version.
>
> > +-- Test is disabled.
> > +--[=[
> > while 1 do
> > local n = x()
> > if n == nil then break end
> > @@ -269,6 +278,7 @@ while 1 do
> > end
> >
> > assert(table.getn(a) == 25 and a[table.getn(a)] == 97)
> > +--]=]
> >
> >
> > -- errors in coroutines
> > diff --git a/test/PUC-Lua-5.1-tests/constructs.lua b/test/PUC-Lua-5.1-tests/constructs.lua
> > index 5fb3798..6776ee6 100644
> > --- a/test/PUC-Lua-5.1-tests/constructs.lua
> > +++ b/test/PUC-Lua-5.1-tests/constructs.lua
> > @@ -200,6 +200,12 @@ a,b = F(nil)==nil; assert(a == true and b == nil)
> >
> > function ID(x) return x end
> >
> > +-- In Lua 5.1 math.mod() is renamed to math.fmod() if build
> > +-- Lua 5.1 without flag `-DLUA_COMPAT_MOD`.
> > +-- LuaJIT also has math.fmod() instead math.mod() builtin.
> > +-- See also https://github.com/tarantool/tarantool/issues/5711.
>
> Ditto.
Ditto.
>
> > +-- Test is disabled.
> > +--[=[
> > function f(t, i)
> > local b = t.n
> > local res = math.mod(math.floor(i/c), b)+1
> > @@ -236,5 +242,6 @@ repeat
> > if math.mod(i,4000) == 0 then print('+') end
> > i = i+1
> > until i==c
> > +--]=]
> >
> > print'OK'
> > diff --git a/test/PUC-Lua-5.1-tests/db.lua b/test/PUC-Lua-5.1-tests/db.lua
> > index 9d2c86f..591a006 100644
> > --- a/test/PUC-Lua-5.1-tests/db.lua
> > +++ b/test/PUC-Lua-5.1-tests/db.lua
> > @@ -95,6 +95,10 @@ repeat
> > assert(g(f) == 'a')
> > until 1
> >
> > +-- LuaJIT interprets a return from calling result of loadstring()
> > +-- with a new line number unlike Lua does.
>
> I don't get the problem neither from comment nor from the issue. Could
> you clarify what is the problem with a line number?
Reworded in the new version.
>
> > +-- See also https://github.com/tarantool/tarantool/issues/5693.
> > +--[=[
> > test([[if
> > math.sin(1)
> > then
> > @@ -149,7 +153,7 @@ end
> > ]], {1,2,1,2,1,3})
> >
> > test([[for i=1,4 do a=1 end]], {1,1,1,1,1})
> > -
> > +--]=]
> >
> >
> > print'+'
> > @@ -178,8 +182,13 @@ function f(a,b)
> > local _, x = debug.getlocal(1, 1)
> > local _, y = debug.getlocal(1, 2)
> > assert(x == a and y == b)
> > - assert(debug.setlocal(2, 3, "pera") == "AA".."AA")
> > - assert(debug.setlocal(2, 4, "ma??") == "B")
> > + -- f() function is called only from g(...) vararg function.
> > + -- Lua 5.1 interprets ... in the vararg functions like additional
> > + -- first argument unlike LuaJIT does.
> > + -- This extension is from Lua 5.2.
> > + -- See also https://github.com/tarantool/tarantool/issues/5694.
> > + -- assert(debug.setlocal(2, 3, "pera") == "AA".."AA")
> > + -- assert(debug.setlocal(2, 4, "ma??") == "B")
> > x = debug.getinfo(2)
> > assert(x.func == g and x.what == "Lua" and x.name == 'g' and
> > x.nups == 0 and string.find(x.source, "^@.*db%.lua"))
> > @@ -208,11 +217,13 @@ function g(...)
> > local feijao
> > local AAAA,B = "xuxu", "mam?o"
> > f(AAAA,B)
> > - assert(AAAA == "pera" and B == "ma??")
> > + -- Test is disabled for LuaJIT for now. See comment in f().
> > + -- assert(AAAA == "pera" and B == "ma??")
> > do
> > local B = 13
> > local x,y = debug.getlocal(1,5)
> > - assert(x == 'B' and y == 13)
> > + -- Test is disabled for LuaJIT for now. See comment in f().
> > + -- assert(x == 'B' and y == 13)
> > end
> > end
> >
> > @@ -276,7 +287,8 @@ debug.sethook(function (e)
> > end, "c")
> >
> > a:f(1,2,3,4,5)
> > -assert(X.self == a and X.a == 1 and X.b == 2 and X.arg.n == 3 and X.c == nil)
> > +-- Test is disabled for LuaJIT for now. See comment in f().
>
> Which one "f()" contains the necessary comment? <a:f> used here has no
> words regarding the problem.
Reimplemented in the new version.
>
> > +-- assert(X.self == a and X.a == 1 and X.b == 2 and X.arg.n == 3 and X.c == nil)
> > assert(XX == 12)
> > assert(debug.gethook() == nil)
> >
> > @@ -314,12 +326,20 @@ assert(debug.setupvalue(io.read, 1, 10) == nil)
> >
> > -- testing count hooks
> > local a=0
> > +-- LuaJIT does not check hooks at traces without defined
> > +-- -DLUAJIT_ENABLE_CHECKHOOK.
> > +-- For more information see <src/lj_record.c> or commit
> > +-- 6bce6b118eeb2bb7f36157de158e5cccf0ea68e5 (Add compile-time
> > +-- option LUAJIT_ENABLE_CHECKHOOK. Disabled by default.).
> > +-- See also https://github.com/tarantool/tarantool/issues/5701.
>
> I guess you can use the first recipe you provided in the issue:
> | local js = jit.status()
> | js and jit.off()
> | <...>
> | js and jit.on()
>
> You can omit the check if it is guaranteed JIT status doesn't change
> from run to run, and leave the corresponding comment.
Done.
>
> > +--[[
> > debug.sethook(function (e) a=a+1 end, "", 1)
> > a=0; for i=1,1000 do end; assert(1000 < a and a < 1012)
> > debug.sethook(function (e) a=a+1 end, "", 4)
> > a=0; for i=1,1000 do end; assert(250 < a and a < 255)
> > local f,m,c = debug.gethook()
> > assert(m == "" and c == 4)
> > +--]]
> > debug.sethook(function (e) a=a+1 end, "", 4000)
> > a=0; for i=1,1000 do end; assert(a == 0)
> > debug.sethook(print, "", 2^24 - 1) -- count upperbound
> > @@ -352,18 +372,24 @@ function g1(x) g(x) end
> >
> > local function h (x) local f=g1; return f(x) end
> >
> > -h(true)
> > +-- LuaJIT does not provide information about tail calls,
> > +-- unlike Lua does. getfenv() behaviour is also different here.
> > +-- Test is disabled for LuaJIT for now.
>
> This looks like an unresolvable issue, doesn't it? So why it is disabled
> *for now*? Furthermore, the ticket lacks the precise description
> regarding the differences, you're talking about.
Test may be adapted for LuaJIT's behaviour.
>
> Minor: BTW, why didn't you comment the whole block? The declarations are
> necessary only for the assertions. Feel free to ignore.
We came to agreement offline not to change unnecessary blocks
to coverage more branches.
>
> > +-- See also https://github.com/tarantool/tarantool/issues/5702.
> > +-- h(true)
> >
> > local b = {}
> > -debug.sethook(function (e) table.insert(b, e) end, "cr")
> > -h(false)
> > -debug.sethook()
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- debug.sethook(function (e) table.insert(b, e) end, "cr")
> > +-- h(false)
> > +-- debug.sethook()
> > local res = {"return", -- first return (from sethook)
> > "call", "call", "call", "call",
> > "return", "tail return", "return", "tail return",
> > "call", -- last call (to sethook)
> > }
> > -for _, k in ipairs(res) do assert(k == table.remove(b, 1)) end
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- for _, k in ipairs(res) do assert(k == table.remove(b, 1)) end
> >
> >
> > lim = 30000
> > @@ -375,7 +401,8 @@ local function foo (x)
> > end
> > end
> >
> > -foo(lim)
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- foo(lim)
> >
> >
> > print"+"
> > @@ -411,7 +438,11 @@ end
> >
> > local co = coroutine.create(f)
> > coroutine.resume(co, 3)
> > -checktraceback(co, {"yield", "db.lua", "tail", "tail", "tail"})
> > +-- LuaJIT does not provide information about tail calls,
> > +-- unlike Lua does.
> > +-- See also https://github.com/tarantool/tarantool/issues/5703.
>
> Ditto. Besides, what is the difference from #5702?
Answered above. The test can be adjusted independently from previous,
so there is separate issue.
>
> > +-- Test is disabled for LuaJIT for now.
> > +-- checktraceback(co, {"yield", "db.lua", "tail", "tail", "tail"})
> >
> >
> > co = coroutine.create(function (x)
> > @@ -429,8 +460,12 @@ local _, l = coroutine.resume(co, 10)
> > local x = debug.getinfo(co, 1, "lfLS")
> > assert(x.currentline == l.currentline and x.activelines[x.currentline])
> > assert(type(x.func) == "function")
> > +-- LuaJIT does not report line with single "end" statement as
> > +-- an active line in debug.getinfo(), unlike Lua does.
>
> Too hard to understand... It's worth to reword the comment considering
> the issue name and make it more verbose.
Reformulated in the new version.
>
> > +-- See also https://github.com/tarantool/tarantool/issues/5708.
> > +-- Test is disabled for LuaJIT for now.
> > for i=x.linedefined + 1, x.lastlinedefined do
> > - assert(x.activelines[i])
> > + -- assert(x.activelines[i])
> > x.activelines[i] = nil
> > end
> > assert(next(x.activelines) == nil) -- no 'extra' elements
> > @@ -441,8 +476,10 @@ a,b = debug.getlocal(co, 1, 2)
> > assert(a == "a" and b == 1)
> > debug.setlocal(co, 1, 2, "hi")
> > assert(debug.gethook(co) == foo)
> > -assert(table.getn(tr) == 2 and
> > - tr[1] == l.currentline-1 and tr[2] == l.currentline)
> > +-- LuaJIT does not support per-coroutine hooks.
>
> Please, mention the issue/doc page with the behaviour description.
Done.
>
> > +-- Test is disabled for LuaJIT.
> > +-- assert(table.getn(tr) == 2 and
> > +-- tr[1] == l.currentline-1 and tr[2] == l.currentline)
> >
> > a,b,c = pcall(coroutine.resume, co)
> > assert(a and b and c == l.currentline+1)
> > @@ -450,9 +487,11 @@ checktraceback(co, {"yield", "in function <"})
> >
> > a,b = coroutine.resume(co)
> > assert(a and b == "hi")
> > -assert(table.getn(tr) == 4 and tr[4] == l.currentline+2)
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- assert(table.getn(tr) == 4 and tr[4] == l.currentline+2)
> > assert(debug.gethook(co) == foo)
> > -assert(debug.gethook() == nil)
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- assert(debug.gethook() == nil)
> > checktraceback(co, {})
> >
> >
> > diff --git a/test/PUC-Lua-5.1-tests/errors.lua b/test/PUC-Lua-5.1-tests/errors.lua
> > index e881211..3270033 100644
> > --- a/test/PUC-Lua-5.1-tests/errors.lua
> > +++ b/test/PUC-Lua-5.1-tests/errors.lua
> > @@ -72,8 +72,12 @@ checkmessage("b=1; local aaa='a'; x=aaa+b", "local 'aaa'")
> > checkmessage("aaa={}; x=3/aaa", "global 'aaa'")
> > checkmessage("aaa='2'; b=nil;x=aaa*b", "global 'b'")
> > checkmessage("aaa={}; x=-aaa", "global 'aaa'")
> > -assert(not string.find(doit"aaa={}; x=(aaa or aaa)+(aaa and aaa)", "'aaa'"))
> > -assert(not string.find(doit"aaa={}; (aaa or aaa)()", "'aaa'"))
> > +-- LuaJIT reports the error as the following here:
> > +-- "attempt to perform arithmetic on global 'aaa' (a table value)"
> > +-- Lua 5.1 doesn't report variable name here.
>
> So the issue is only in different error message? It's unclear from you
> message (I've got this only at the third attempt).
It tests only error messages, described it more verbosly in the new
version.
>
> > +-- Test is disabled for LuaJIT.
> > +-- assert(not string.find(doit"aaa={}; x=(aaa or aaa)+(aaa and aaa)", "'aaa'"))
> > +-- assert(not string.find(doit"aaa={}; (aaa or aaa)()", "'aaa'"))
> >
> > checkmessage([[aaa=9
> > repeat until 3==3
> > @@ -100,9 +104,12 @@ while 1 do
> > insert(prefix, a)
> > end]], "global 'insert'")
> >
> > -checkmessage([[ -- tail call
> > - return math.sin("a")
> > -]], "'sin'")
> > +-- Implementation of fast functions in LuaJIT does not provide
> > +-- enough info on failure.
>
> What info do fast functions lack? Not an issue. Not a word. The comment
> just to comment...
Reworded in the new version.
>
> > +-- Test is disabled for LuaJIT.
> > +-- checkmessage([[ -- tail call
> > +-- return math.sin("a")
> > +-- ]], "'sin'")
> >
> > checkmessage([[collectgarbage("nooption")]], "invalid option")
> >
> > @@ -193,7 +200,11 @@ checksyntax("[[a]]", "", "[[a]]", 1)
> > checksyntax("'aa'", "", "'aa'", 1)
> >
> > -- test 255 as first char in a chunk
> > -checksyntax("\255a = 1", "", "\255", 1)
> > +-- LuaJIT does not avoid to use non-alphabetic symbols
>
> Minor: I guess you mean alphanumeric, not alphabetic.
Fixed.
>
> > +-- as identifiers, unlike Lua does.
> > +-- For more details see <src/lj_char.c> and <src/lj_lex.c>.
> > +-- Test is disabled for LuaJIT.
> > +-- checksyntax("\255a = 1", "", "\255", 1)
> >
> > doit('I = loadstring("a=9+"); a=3')
> > assert(a==3 and I == nil)
> > @@ -215,7 +226,10 @@ local function testrep (init, rep)
> > end
> > testrep("a=", "{")
> > testrep("a=", "(")
> > -testrep("", "a(")
> > +-- When compiled with LUAJIT_ENABLE_GC64 LJ_MAX_SLOTS limit
> > +-- is reached and error is LJ_ERR_XSLOTS ("function or expression too
> > +-- complex"). Test is disabled for LuaJIT.
>
> And what is the expected behaviour?
See the test above. Answered in the new version.
>
> > +-- testrep("", "a(")
> > testrep("", "do ")
> > testrep("", "while a do ")
> > testrep("", "if a then else ")
> > diff --git a/test/PUC-Lua-5.1-tests/gc.lua b/test/PUC-Lua-5.1-tests/gc.lua
> > index 86a9f75..b767104 100644
> > --- a/test/PUC-Lua-5.1-tests/gc.lua
> > +++ b/test/PUC-Lua-5.1-tests/gc.lua
> > @@ -108,11 +108,16 @@ local function dosteps (siz)
> > return i
> > end
> >
> > +-- JIT compilation can unpredictable allocate or reference objects
> > +-- (or traces itself). Disable it for this chunk for stable
> > +-- GC results.
>
> Is JIT unconditionally enabled? If it's not, it is unconditionally
> enabled "back" below... If it is, please mention this in the comment.
Applied.
>
> Side note: amazingly, you didn't comment these assertions but adjust the
> block... It's better, but inconsistent with the other changes.
>
> > +jit.off()
> > assert(dosteps(0) > 10)
> > assert(dosteps(6) < dosteps(2))
> > assert(dosteps(10000) == 1)
> > assert(collectgarbage("step", 1000000) == true)
> > assert(collectgarbage("step", 1000000))
> > +jit.on()
> >
> >
> > do
> > diff --git a/test/PUC-Lua-5.1-tests/literals.lua b/test/PUC-Lua-5.1-tests/literals.lua
> > index 01d84d5..ee16a3e 100644
> > --- a/test/PUC-Lua-5.1-tests/literals.lua
> > +++ b/test/PUC-Lua-5.1-tests/literals.lua
> > @@ -158,6 +158,10 @@ end
> >
> >
> > -- testing decimal point locale
> > +-- LuaJIT doesn't use `strtod()` depended on the locale, unlike
> > +-- Lua does. See <src/lj_strscan.c> for more info.
>
> I see the related issue in LuaJIT queue[1] (looks like <os.setlocale>
> does nothing for many case). Please mention it here.
It just mentioned documentation, see no reason to reference this issue
here.
>
> > +-- Tests are disabled for LuaJIT.
> > +--[[
> > if os.setlocale("pt_BR") or os.setlocale("ptb") then
> > assert(tonumber("3,4") == 3.4 and tonumber"3.4" == nil)
> > assert(assert(loadstring("return 3.4"))() == 3.4)
> > @@ -171,6 +175,7 @@ else
> > (Message or print)(
> > '\a\n >>> pt_BR locale not available: skipping decimal point tests <<<\n\a')
> > end
> > +--]]
> >
> >
> > print('OK')
> > diff --git a/test/PUC-Lua-5.1-tests/main.lua b/test/PUC-Lua-5.1-tests/main.lua
> > index f520896..12f3981 100644
> > --- a/test/PUC-Lua-5.1-tests/main.lua
> > +++ b/test/PUC-Lua-5.1-tests/main.lua
> > @@ -65,9 +65,16 @@ a = string.format(a, progname)
> > prepfile(a)
> > RUN('lua "-e " -- %s a b c', prog)
> >
> > -prepfile"assert(arg==nil)"
> > -prepfile("assert(arg)", otherprog)
> > -RUN("lua -l%s - < %s", prog, otherprog)
> > +-- test 'arg' availability in libraries
> > +-- LuaJIT v2.1.0-beta3 has extension from Lua 5.3:
> > +-- The argument table `arg` can be read (and modified)
> > +-- by `LUA_INIT` and `-e` chunks.
> > +-- See commit 92d9ff211ae864777a8580b5a7326d5f408161ce
> > +-- (Set arg table before evaluating LUA_INIT and -e chunks.).
> > +-- See also https://github.com/tarantool/tarantool/issues/5686.
> > +-- prepfile"assert(arg==nil)"
> > +-- prepfile("assert(arg)", otherprog)
> > +-- RUN("lua -l%s - < %s", prog, otherprog)
> >
> > prepfile""
> > RUN("lua - < %s > %s", prog, out)
> > @@ -89,26 +96,35 @@ prepfile[[
> > RUN("lua - < %s > %s", prog, out)
> > checkout("1\tnil\n")
> >
> > +-- Version and status are printed in stdout instead stderr since
> > +-- LuaJIT-2.0.0-beta11 (as it is not an error message).
> > +-- See commit 0bd1a66f2f055211ef55834ccebca3b82d03c735
> > +-- (Print version and JIT status to stdout, not stderr.).
> > +-- This behavior is the same as in Lua 5.2.
> > +-- See also https://github.com/tarantool/tarantool/issues/5687.
> > prepfile[[
> > = (6*2-6) -- ===
> > a
> > = 10
> > print(a)
> > = a]]
> > -RUN([[lua -e"_PROMPT='' _PROMPT2=''" -i < %s > %s]], prog, out)
> > -checkout("6\n10\n10\n\n")
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- RUN([[lua -e"_PROMPT='' _PROMPT2=''" -i < %s > %s]], prog, out)
> > +-- checkout("6\n10\n10\n\n")
> >
> > prepfile("a = [[b\nc\nd\ne]]\n=a")
> > print(prog)
> > -RUN([[lua -e"_PROMPT='' _PROMPT2=''" -i < %s > %s]], prog, out)
> > -checkout("b\nc\nd\ne\n\n")
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- RUN([[lua -e"_PROMPT='' _PROMPT2=''" -i < %s > %s]], prog, out)
> > +-- checkout("b\nc\nd\ne\n\n")
> >
> > prompt = "alo"
> > prepfile[[ --
> > a = 2
> > ]]
> > -RUN([[lua "-e_PROMPT='%s'" -i < %s > %s]], prompt, prog, out)
> > -checkout(string.rep(prompt, 3).."\n")
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- RUN([[lua "-e_PROMPT='%s'" -i < %s > %s]], prompt, prog, out)
> > +-- checkout(string.rep(prompt, 3).."\n")
> >
> > s = [=[ --
> > function f ( x )
> > @@ -126,19 +142,29 @@ assert( a == b )
> > =f( 11 ) ]=]
> > s = string.gsub(s, ' ', '\n\n')
> > prepfile(s)
> > -RUN([[lua -e"_PROMPT='' _PROMPT2=''" -i < %s > %s]], prog, out)
> > -checkout("11\n1\t2\n\n")
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- RUN([[lua -e"_PROMPT='' _PROMPT2=''" -i < %s > %s]], prog, out)
> > +-- checkout("11\n1\t2\n\n")
> >
> > prepfile[[#comment in 1st line without \n at the end]]
> > RUN("lua %s", prog)
> >
> > +-- test loading and running bytecode files.
> > +-- Loading bytecode with an extra header (BOM or "#") is disabled
> > +-- for security reasons since LuaJIT-2.0.0-beta10.
> > +-- For more information see comment for lj_lex_setup()
> > +-- in <src/lj_lex.c>.
> > +-- Also see commit 53a285c0c3544ff5dea7c67b741c3c2d06d22b47
> > +-- (Disable loading bytecode with an extra header (BOM or #!).).
> > +-- See also https://github.com/tarantool/tarantool/issues/5691.
> > prepfile("#comment with a binary file\n"..string.dump(loadstring("print(1)")))
> > -RUN("lua %s > %s", prog, out)
> > -checkout("1\n")
> > +-- RUN("lua %s > %s", prog, out)
> > +-- checkout("1\n")
> >
> > prepfile("#comment with a binary file\r\n"..string.dump(loadstring("print(1)")))
> > -RUN("lua %s > %s", prog, out)
> > -checkout("1\n")
> > +-- Behavior is different for LuaJIT. See the comment above.
> > +-- RUN("lua %s > %s", prog, out)
> > +-- checkout("1\n")
> >
> > -- close Lua with an open file
> > prepfile(string.format([[io.output(%q); io.write('alo')]], out))
> > diff --git a/test/PUC-Lua-5.1-tests/math.lua b/test/PUC-Lua-5.1-tests/math.lua
> > index 5076f38..b46a3f5 100644
> > --- a/test/PUC-Lua-5.1-tests/math.lua
> > +++ b/test/PUC-Lua-5.1-tests/math.lua
> > @@ -100,7 +100,12 @@ assert(math.abs(-10) == 10)
> > assert(eq(math.atan2(1,0), math.pi/2))
> > assert(math.ceil(4.5) == 5.0)
> > assert(math.floor(4.5) == 4.0)
> > -assert(math.mod(10,3) == 1)
> > +-- In Lua 5.1 math.mod() is renamed to math.fmod() if build
> > +-- Lua 5.1 without flag `-DLUA_COMPAT_MOD`.
> > +-- LuaJIT also has math.fmod() instead math.mod() builtin.
> > +-- See also https://github.com/tarantool/tarantool/issues/5711.
>
> The same as for math.mod occurrence above.
Answered above.
>
> > +-- Test is disabled.
> > +-- assert(math.mod(10,3) == 1)
> > assert(eq(math.sqrt(10)^2, 10))
> > assert(eq(math.log10(2), math.log(2)/math.log(10)))
> > assert(eq(math.exp(0), 1))
> > diff --git a/test/PUC-Lua-5.1-tests/nextvar.lua b/test/PUC-Lua-5.1-tests/nextvar.lua
> > index 7ceaa75..a63f97e 100644
> > --- a/test/PUC-Lua-5.1-tests/nextvar.lua
> > +++ b/test/PUC-Lua-5.1-tests/nextvar.lua
> > @@ -199,6 +199,12 @@ _G["xxx"] = 1
> > assert(xxx==find("xxx"))
> > print('+')
> >
> > +-- In Lua 5.1 math.mod() is renamed to math.fmod() if build
> > +-- Lua 5.1 without flag `-DLUA_COMPAT_MOD`.
> > +-- LuaJIT also has math.fmod() instead math.mod() builtin.
> > +-- See also https://github.com/tarantool/tarantool/issues/5711.
>
> The same as for math.mod occurrence above.
Answered above.
>
> > +-- Test is disabled.
> > +--[=[
> > a = {}
> > for i=0,10000 do
> > if math.mod(i,10) ~= 0 then
> > @@ -213,6 +219,7 @@ for i,v in pairs(a) do
> > end
> > assert(n.n == 9000)
> > a = nil
> > +--]=]
> >
> > -- remove those 10000 new global variables
> > for i=1,10000 do _G[i] = nil end
> > diff --git a/test/PUC-Lua-5.1-tests/pm.lua b/test/PUC-Lua-5.1-tests/pm.lua
> > index fa125dc..366a31c 100644
> > --- a/test/PUC-Lua-5.1-tests/pm.lua
> > +++ b/test/PUC-Lua-5.1-tests/pm.lua
> > @@ -223,7 +223,11 @@ assert(string.gsub("a alo b hi", "%w%w+", t) == "a ALO b HI")
> >
> >
> > -- tests for gmatch
> > -assert(string.gfind == string.gmatch)
> > +-- In Lua 5.1 function string.gfind was renamed to string.gmatch.
> > +-- You can use it if Lua 5.1 is built with compile-time option
> > +-- `-DLUA_COMPAT_GFIND`.
> > +-- This builtin is removed from LuaJIT. Test is disabled.
>
> Just remove the test in a separate commit and mention the patch that
> removes the builtin. I see no reason for disabling this test.
Done. I've failed to find this patch grepped by 'gfind', can you provide
reference to it please? I supposed it has be done before v2.0 is
released.
>
> > +-- assert(string.gfind == string.gmatch)
> > local a = 0
> > for i in string.gmatch('abcde', '()') do assert(i == a+1); a=i end
> > assert(a==6)
> > diff --git a/test/PUC-Lua-5.1-tests/strings.lua b/test/PUC-Lua-5.1-tests/strings.lua
> > index 237dbad..a97c888 100644
> > --- a/test/PUC-Lua-5.1-tests/strings.lua
> > +++ b/test/PUC-Lua-5.1-tests/strings.lua
> > @@ -102,7 +102,18 @@ print('+')
> >
> > x = '"?lo"\n\\'
> > assert(string.format('%q%s', x, x) == '"\\"?lo\\"\\\n\\\\""?lo"\n\\')
> > -assert(string.format('%q', "\0") == [["\000"]])
> > +-- LuaJIT since v2.0.0-beta6 has extension from Lua 5.2:
> > +-- string.format(): %q reversible.
> > +-- In Lua 5.1 string.format() does not accept string values
> > +-- containing embedded zeros, except as arguments to the q option.
> > +-- In Lua 5.2 '\0' is not handled differently from other
> > +-- control chars in string.format('%q', ...).
> > +-- See commit 7cc981c14067d4b0e774a6bfb0acfc2f5c911f0d
> > +-- (string.format("%q", str) is now fully reversible
> > +-- (from Lua 5.2).).
> > +-- See also https://github.com/tarantool/tarantool/issues/5710.
> > +-- Test is disabled for LuaJIT for now.
> > +-- assert(string.format('%q', "\0") == [["\000"]])
> > assert(string.format("\0%c\0%c%x\0", string.byte("?"), string.byte("b"), 140) ==
> > "\0?\0b8c\0")
> > assert(string.format('') == "")
> > @@ -152,6 +163,9 @@ local function trylocale (w)
> > return false
> > end
> >
> > +-- LuaJIT doesn't compare strings by `strcoll`, like Lua 5.1 does.
> > +-- Tests are disabled for LuaJIT.
> > +--[[
> > if not trylocale("collate") then
> > print("locale not supported")
> > else
> > @@ -166,6 +180,7 @@ else
> > assert(string.gsub("????", "%u", "x") == "?x?x")
> > assert(string.upper"???{xuxu}??o" == "???{XUXU}??O")
> > end
> > +--]]
> >
> > os.setlocale("C")
> > assert(os.setlocale() == 'C')
> > diff --git a/test/PUC-Lua-5.1-tests/vararg.lua b/test/PUC-Lua-5.1-tests/vararg.lua
> > index ae068fa..e2de1ad 100644
> > --- a/test/PUC-Lua-5.1-tests/vararg.lua
> > +++ b/test/PUC-Lua-5.1-tests/vararg.lua
> > @@ -21,9 +21,14 @@ function vararg (...) return arg end
> >
> > local call = function (f, args) return f(unpack(args, 1, args.n)) end
> >
> > -assert(f() == 0)
> > -assert(f({1,2,3}, 1, 2, 3) == 3)
> > -assert(f({"alo", nil, 45, f, nil}, "alo", nil, 45, f, nil) == 5)
> > +-- Lua 5.1 interprets ... in the vararg functions like additional
> > +-- first argument unlike LuaJIT does. All extra arguments is set
> > +-- into `arg` variable. This extension is from Lua 5.2.
> > +-- See also https://github.com/tarantool/tarantool/issues/5712.
> > +-- Test is disabled for LuaJIT.
> > +-- assert(f() == 0)
> > +-- assert(f({1,2,3}, 1, 2, 3) == 3)
> > +-- assert(f({"alo", nil, 45, f, nil}, "alo", nil, 45, f, nil) == 5)
> >
> > assert(c12(1,2)==55)
> > a,b = assert(call(c12, {1,2}))
> > @@ -35,15 +40,18 @@ assert(not a)
> > assert(c12(1,2,3) == false)
> > local a = vararg(call(next, {_G,nil;n=2}))
> > local b,c = next(_G)
> > -assert(a[1] == b and a[2] == c and a.n == 2)
> > +-- Test is disabled for LuaJIT for now. See the comment above.
> > +-- assert(a[1] == b and a[2] == c and a.n == 2)
> > a = vararg(call(call, {c12, {1,2}}))
> > -assert(a.n == 2 and a[1] == 55 and a[2] == 2)
> > +-- Test is disabled for LuaJIT for now. See the comment above.
> > +-- assert(a.n == 2 and a[1] == 55 and a[2] == 2)
> > a = call(print, {'+'})
> > assert(a == nil)
> >
> > local t = {1, 10}
> > function t:f (...) return self[arg[1]]+arg.n end
> > -assert(t:f(1,4) == 3 and t:f(2) == 11)
> > +-- Test is disabled for LuaJIT for now. See the comment above.
> > +-- assert(t:f(1,4) == 3 and t:f(2) == 11)
> > print('+')
> >
> > lim = 20
> > --
> > 2.28.0
> >
>
> [1]: https://github.com/LuaJIT/LuaJIT/issues/673
>
> --
> Best regards,
> IM
[1]: https://lists.tarantool.org/pipermail/tarantool-patches/2021-March/022979.html
--
Best regards,
Sergey Kaplun
More information about the Tarantool-patches
mailing list