Code generation patches for fuzzer (feedback requested)

[A. Sundararajan]

As we are approaching towards jdk8 end game, it is better to avoid 
sweeping changes at the last minute.

I think we can definitely consider these changes for post jdk8 (8 update 
perhaps..).

PS. As you know, not all your previous 'fuzzer' issues have been fixed 
for jdk8 - again due to time constraints.

Thanks for reporting,
-Sundar

On Tuesday 15 October 2013 04:46 PM, André Bargull wrote:
> (5) EnforceObjectTypeForNull.patch
>
> This one looks like a bug in asm's frame computation, adding a 
> `checkcast` instruction makes sure things work as expected...
>
> test cases:
> function f(){ try { var x = 1, x = null; } catch(x2) {} }
> function f(){ try { var x = 1; x = null; } catch(x2) {} return x }
>
> - André
>
> On 10/15/2013 10:45 AM, André Bargull wrote:
>> I've needed to apply the following patches to continue fuzzing. If 
>> those changes look reasonable, can someone make sure they get into 
>> the upstream repo?
>>
>> - André
>>
>>
>> (1) IncompatibleAssignmentCoercion.patch:
>>
>> `Type.widest(Type, Type)` can promote boolean -> number, or number -> 
>> string. This is not wanted for (?:) - ConditionalExpressions or 
>> ReturnStatements. Added a new uncoercedWidest(Type, Type) method to 
>> Attr which makes sure only valid promotions are applied.
>>
>> test cases:
>> /* no verify error */ function f1(c,x){ c (x ? [1] : 1); }
>> function f2(c,x){ c = (x ? "123" : 1); return c }
>> typeof f2(null,true) === "string"
>> typeof f2(null,false) === "number"
>> function f3(v){if (v) return 123; else return true}
>> f3(true) === 123
>> f3(false) === true
>>
>>
>> (2) JDK-8026249-WidenDISCARD.patch:
>>
>> The left-hand side of a BinaryNode does not have a Type if it is a 
>> Discard node, that means `lhs.getType()` may throw an assertion 
>> error. Moving the Type.widest() calls makes sure `lhs.getType()` is 
>> only called when it is safe to do.
>>
>> test case:
>> /* no assertion */ function f() { if(x3, y) x; }
>>
>>
>> (3) JDK-8026249-EnsureTypeDiscard.patch:
>>
>> The type for a CommaRight BinaryNode is based on the right-hand 
>> side's type, make sure the RHS always has a proper type attached. 
>> [I've also fixed this for CommaLeft, but that one isn't actually 
>> used, is it?]
>>
>> test case:
>> /* no assertion */ function f(x) { return y, x }
>>
>>
>> (4) JDK-8026249-ControlFlowEscape.patch:
>>
>> Control flow may escape from SwitchNode or LabelNode through `break` 
>> or `continue` statements. Simply moving the "controlFlowEscapes" 
>> logic from LoopNode to BreakableStatement solves the SwitchNode 
>> issue. And for LabelNode just clear the "terminal" on its body node.
>>
>> test cases:
>> /* no verify error / NPE */ function f() { L: { try { return 1; } 
>> finally { break L; }} }
>> /* no verify error / NPE */ function f() { L: { if (v) break L; 
>> return} }
>> /* no verify error / NPE */ function f() { L: {{ break L; } return; } }
>> /* no verify error / NPE */ function f() { L: { if (x2) { break L; } 
>> throw x; } }
>> /* no verify error / NPE */ function f() { switch(v) { default: if(v) 
>> break; return; } }
>> /* no verify error / NPE */ function f() { switch(x) { default: 
>> if(true) break; return; } }
>> /* no verify error / NPE */ function f() { switch(x) { default: L: 
>> break; return; } }
>