[NoW] Weird line# for CLOSURE instruction

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[NoW] Weird line# for CLOSURE instruction

Egor Skriptunoff-2
"NoW" means "Nitpicking on Wednesdays"
(unimportant questions about Lua design and implementation)
 
Hi!
 
Let's look at the listing of very simple Lua program:
 
C:\>luac53.exe -l -p -
   local x          -- [1]
   function f()     -- [2]
     x = x + 1      -- [3]
   end              -- [4]
   x = 0            -- [5]
^Z

 
main <stdin:0,0> (5 instructions at 000000000017A0B0)
0+ params, 2 slots, 1 upvalue, 1 local, 2 constants, 1 function
        1       [1]     LOADNIL         0 0
        2       [4]     CLOSURE         1 0     ; 000000000017A2B0
        3       [2]     SETTABUP        0 -1 1  ; _ENV "f"
        4       [5]     LOADK           0 -2    ; 0
        5       [5]     RETURN          0 1
 
function <stdin:2,4> (4 instructions at 000000000017A2B0)
0 params, 2 slots, 1 upvalue, 0 locals, 1 constant, 0 functions
        1       [3]     GETUPVAL        0 0     ; x
        2       [3]     ADD             0 0 -1  ; - 1
        3       [3]     SETUPVAL        0 0     ; x
        4       [4]     RETURN          0 1
 
The source line numbers assigned to main chunk's instructions are:
[1], [4], [2], [5], [5].
These line numbers are designed for using in Lua debuggers
as a list of breakpointable lines.
 
As you see, the sequence of these line# is NOT monotonic.
During the program execution under a debugger, the cursor
(the line in the source text corresponding to the current VM instruction)
would jump down and then up and then again down,
although the program doesn't have gotos/loops.
This is not nice.
 
More serious problem is that if user sets a breakpoint at line#4
to catch the moment when the function f is exiting
(line#4 is the instruction RETURN inside function f),
the breakpoint will be triggered
NOT during the first invocation of the function f (as user expects),
but on the definition of function f.
Such behavior is obviously wrong.
 
It's very strange that the CLOSURE instruction corresponds
to the LAST line of the function being created.
To make things look more naturally, CLOSURE instruction should have
its line# pointing to the FIRST line of the function.