RE: code generation bug

["Kelley, Brian" <bkelley@...>]

> Not surprisingly, the dual case has the same bug:
> 
>   > = ((nil and true) or false) and true
>   nil
>   > f=false
>   > = ((nil and true) or f) and true
>   false


Or more generally, for any Y, Z:

    ((nil and Y) or false) and Z  -->  nil
    (nil and Y) or (false and Z)  -->  nil

Which is symmetrical with my earlier generalization:  For any X, Y, Z, where X ~=nil and X~=false:

    ((X or Y) and true) or Z  -->  X
    (X or Y) and (true or Z)  -->  X


> > For what it's worth, I observed in lcode.c that the OPR_AND
> expression
> > inherited the 'k' (kind) of VTRUE from its rhs subexpression,
> > which seems wrong and seems to throw off the subsequent call to
> > luaK_goiffalse().
> 
> Well, the result of "((1 or false) and true)" is true, so the
> inherited
> attribute VTRUE is not completely wrong. The problem seems to be the
> interaction between this attribute and the patch lists. (But I still
> need some time to check this bug...)

Got it.  I didn't have time to grok the code generation, but offered this info in case it might help a bit.

-bhk