lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>>>>> "Xmilia" == Xmilia Hermit <xmilia.hermit@gmail.com> writes:

 Xmilia> Hi,

 Xmilia> I think I just found a bug regarding to-be-closed variables.
 Xmilia> For some reason the forth to-be-closed variable of a for-in
 Xmilia> loop has problems to close with a tailcall as can be seen in
 Xmilia> the following example.

Yes, this is definitely a bug. I think the problem is that the compiler
is not recognizing that return tail() should not actually be a tail call
(since a toclose variable is in scope) and is compiling it as if it is,
which leaves the stack and its to-close marks in an inconsistent state.

Specifically the test() bytecode is:

function <l2.lua:17,21> (10 instructions at 0x800a32280)
0 params, 7 slots, 2 upvalues, 5 locals, 0 constants, 0 functions
        1       [18]    GETUPVAL        0 0     ; pairs_with_close
        2       [18]    CALL            0 1 5   ; 0 in 4 out
        3       [18]    TFORPREP        0 3     ; to 7
        4       [19]    GETUPVAL        5 1     ; tail
        5       [19]    TAILCALL        5 1 0   ; 0 in
        6       [19]    RETURN          5 0 0   ; all out
        7       [18]    TFORCALL        0 1
        8       [18]    TFORLOOP        0 5     ; to 4
        9       [20]    CLOSE           0
        10      [21]    RETURN          0 1 0   ; 0 out

This looks like a simple oversight in forlist() in lparser.c, which is
calling markupval on the close variable but not setting bl->insidetbc to
signal that a close var is in scope.

-- 
Andrew.