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

[Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

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.

> 
> > 
> > This patch disables test that checks name of built-in functions
> 
> Typo: s/disables test/disables the test/.
> Typo: s/checks name/checks the name/.

Fixed.

> 
> > reported in error in tail call.
> > 
> > Part of tarantool/tarantool#5845
> > Part of tarantool/tarantool#4473
> > ---
> >  test/PUC-Lua-5.1-tests/errors.lua | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > 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:

| 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