708079 - [ASC BUG] ASC issues non-sensical strict mode errors with bitwise operators used inside logical operators.

Status: VERIFIED FIXED

(Tamarin Graveyard :: Tools, defect, P2)

Description

[Erik Tierney]

Compile the following code in strict mode with new ASC:

var x, y, z;
if(!(x & y || y & z))
{
}

Produces these errors:


[Compiler] Error #1067: Implicit coercion of a value of type Boolean to an unrelated type int.
   test.as, Ln 3, Col 6: 
   if(!(x & y || y & z))
   .....^

[Compiler] Error #1067: Implicit coercion of a value of type Boolean to an unrelated type int.
   test.as, Ln 3, Col 15: 
   if(!(x & y || y & z))
   ..............^

Comment 1

[Erik Tierney]

Both the ! and || are important - remove either one and the error goes away

Comment 2

[Erik Tierney]

Has to do with the code in ConstantEvaluator.evaluate(Context, UnaryExressionNode)

It first coerces the expression to Boolean, but then it realizes that the expression will evaluate to int so it tries to use the int version of logical not (it has overloads for Boolean and int - it ends up with the SLOT_Global_LogicalNotOp_I).  That slot expects an int as an argument, so it tries to coerce the expression back to int, and we get the error.

However, for a simpler expression, such as:

if( !(x&y) ) {}

The first coerce to Boolean appears to be a no-op, so the later coerce to int works fine.  

For some reason coerce is acting differently for the broken expression with the logical-or (there is special case code to push the coerce down to each branch of the logical-or, but I don't see why that would be different than the simpler case).

Comment 3

[Erik Tierney]

One workaround is to remove the overload for int from the logical not (In GlobalBuilder.initGlobalObject).  ASC does not appear to do anything different for the overload, so it doesn't seem to have any effect on the generated code.

Comment 4

[Lars T Hansen]

(In reply to Erik Tierney from comment #3)
> One workaround is to remove the overload for int from the logical not (In
> GlobalBuilder.initGlobalObject).  ASC does not appear to do anything
> different for the overload, so it doesn't seem to have any effect on the
> generated code.

I'll do that then.  With the additional test case in place in test/acceptance/as3/asc in Tamarin we'll catch the problem quickly if we have to revert the change.

Comment 5

[Lars T Hansen]

changeset:   81:7fac3b522db5
tag:         tip
user:        Lars T Hansen <[e-mail]>
date:        Wed Dec 07 17:07:44 2011 +0100
summary:     Workaround [ASC BUG] ASC issues non-sensical strict mode errors with bitwise operators used inside logical operators

Comment 6

[Lars T Hansen]

tr-float:

changeset:   7048:2e3b3a868c0a
tag:         tip
user:        Lars T Hansen <[e-mail]>
date:        Wed Dec 07 17:08:57 2011 +0100
summary:     Updated asc.jar to asc-float 81:7fac3b522db5; test case added