[Tarantool-patches] [PATCH v2 luajit 23/30] test: disable PUC Lua test for fast function name

[Igor Munkin]

Sergey,

On 02.04.21, Sergey Kaplun wrote:
> Igor,
> 
> Thanks for the review!
> 
> On 31.03.21, Igor Munkin wrote:
> > Sergey,
> > 
> > Thanks for the patch! Please consider the comments below.
> > 
> > On 26.03.21, Sergey Kaplun wrote:
> > > LuaJIT can't determine bytecode position for non Lua functions
> > > (in particular for fast functions) and, therefore, detect built-in
> > > function names for errors in tail calls.
> > 
> > Side note: here is the inconsistency in your usage of possessive nouns.
> 
> Fixed.

No, it's not, but this doesn't bother me anymore.

> 

<snipped>

> > > diff --git a/test/PUC-Lua-5.1-tests/errors.lua b/test/PUC-Lua-5.1-tests/errors.lua
> > > index cf24e40..af776a7 100644
> > > --- a/test/PUC-Lua-5.1-tests/errors.lua
> > > +++ b/test/PUC-Lua-5.1-tests/errors.lua
> > > @@ -105,9 +105,13 @@ while 1 do
> > >    insert(prefix, a)
> > >  end]], "global 'insert'")
> > >  
> > > -checkmessage([[  -- tail call
> > > -  return math.sin("a")
> > > -]], "'sin'")
> > > +-- LuaJIT: Can't determine bytecode position for non Lua functions
> > > +-- (in particular for fast functions) and, therefore, detect fast
> > > +-- function names for errors in tail calls.
> > 
> > This is kinda gibberish. I've tried the following snippets and can't
> > understand what do you mean by this comment.
> > 
> > | $ luajit -e 'function q(a) return math.sin(a) end q("a")'
> > | luajit: (command line):1: bad argument #1 to 'q' (number expected, got string)
> > | stack traceback:
> > |         [C]: in function 'q'
> > |         (command line):1: in main chunk
> > |         [C]: at 0x5610e8497eb0
> > | $ luajit -e 'loadstring("return math.sin([[a]])")()'
> > | luajit: (command line):1: bad argument #1 to '?' (number expected, got string)
> > | stack traceback:
> > |         [builtin#43]: at 0x7fc0f807ad10
> > |         (command line):1: in main chunk
> > |         [C]: at 0x55c1e85c7eb0
> > 
> > I understand the first result. The second result surprised me, but I've
> > never investigated how loadstring call works (it looks like specifics of
> > VARG frame, but this is a wild guess). But neither of them fits your
> > explanation. The root cause is the same: callee uses caller frame, since
> > caller doesn't need it anymore. Could you please clarify yours?
> 
> This is not about `loadstring()` at all:
> 
> | luajit -e 'return math.sin"a"'
> | luajit: bad argument #1 to '?' (number expected, got string)
> | stack traceback:
> |         [builtin#43]: at 0x7f7c2ca6dbe0
> |         [C]: at 0x558b0cd4cec0
> 
> The guest frame is looked like the following (when the error thrown):
> | 0x40001938            [    ] VALUE: string "number expected, got string" @ 0x40008380
> | 0x40001930            [ B  ] VALUE: string "a" @ 0x40008250
> | 0x40001928            [    ] FRAME: [CP] delta=3, fast function #44
> 
> When LuaJIT tries to detect function's name it determines bytecode
> position first, via `debug_framepc()`. But it can't determine bytecode
> position for non-Lua functions:

What? Both luajit-gdb.py and LuaJIT itself reports the fast function ID
and this is its name.

> 
> | if (!isluafunc(fn)) {  /* Cannot derive a PC for non-Lua functions. */
> |   return NO_BCPOS;
> 
> > 
> > > +-- The test is disabled for LuaJIT.
> > > +-- checkmessage([[  -- tail call
> > > +--   return math.sin("a")
> > > +-- ]], "'sin'")
> > >  
> > >  checkmessage([[collectgarbage("nooption")]], "invalid option")
> > >  
> > > -- 
> > > 2.31.0
> > > 
> > 
> > -- 
> > Best regards,
> > IM
> 
> -- 
> Best regards,
> Sergey Kaplun

-- 
Best regards,
IM