Re: [Tarantool-patches] [PATCH v2 1/3] test: corrected reported error lines

[Igor Munkin via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Timur,

On 30.06.21, Timur Safin wrote:
> : From: Igor Munkin <imun@tarantool.org>
> : Subject: Re: [Tarantool-patches] [PATCH v2 1/3] test: corrected reported
> : error lines
> : 
> : Timur,
> : 
>  
> : > :
> : > : Minor: Strictly saying :123 part is also broken.
> : >
> : > O_o, why? Could you please clarify? We report it as line number in the
> : > source file, in this case tkt-9a8b09f8e6.test.lua:123 was exactly the
> : > caller location?
> : 
> : Do you need the location of definition (:123) or location where the
> : function execution is stopped at the moment (:142)? If I got your point,
> : you prefer the latter, right?
> 
> FWIW, currentline is pointing _exactly_ to the line number in the file
> Which was calling this error, not to the start of function definition. 

Yes, this is written in Lua Reference Manual[1].

> At least in our cases, when we not introduce any extra do scopes.

What is wrong with extra do scopes?

> 
> [Now I start to worry with the question when .linedefined is not 0
> and whether we would need to sum .currentline and .linedefined to 
> get actual source line in the file?]
> 
> : > if currentline may be missing in the traceback object for any reason.
> : 
> : It may not, considering the flags used for obtaining debug info.
> : 
> : > If it's impossible for the set of requested flags, then I'll get rid
> : > of linedefined here.
> : 
> : Yes, <currentline> field is provided by 'l' flag[1]. Please, get rid of
> : <linedefined> and the default 0 and drop a few sentences regarding this
> : change in commit message.
> 
> Please see my worries about .linedefined above. Currently it's in main scope,
> when it will be not main scope, do any extra do create separate scope? 

Lexical blocks are described here[2].

> Could .currentline be .linedefined related or it's guaranteed to be 
> Counted from start of file?

I see nothing about such odd behaviour in Reference Manual[1], but you
can check manually whether LuaJIT works fine in this case.

> 
> : 
> : [1]: https://www.lua.org/manual/5.1/manual.html#lua_getinfo
> : 
> : --
> : Best regards,
> : IM
> 

[1]: https://www.lua.org/manual/5.1/manual.html#3.8
[2]: https://www.lua.org/manual/5.1/manual.html#2.4.2

-- 
Best regards,
IM