Currently the SquirrelFish branch fails (or crashes on) 287 of the JavaScriptCore regression tests. We need to pass them all to be able to land on trunk. Individual issues that block passing the JSC regression tests should be filed as blockers of this bug.
Created attachment 20689 [details] current failures (the "fixed" are probably also failures)
Created attachment 20690 [details] HTML results from running the tests - should give more details of the failures
As of r32291 we only fail 144 of the JSC regression tests, compiling debug.
Created attachment 20719 [details] the latest list of failures
Created attachment 20720 [details] latest results file
Created attachment 20734 [details] Latest list of failures Here is the latest list of failures. We only have 79 regressions left, plus 5 possibly dubious fixes.
Created attachment 20735 [details] Latest results file
Down to 51 regressions now.
Down to 41.
Created attachment 20749 [details] Latest list of failures Here is the latest list of failures. There are 44 failures and no 'fixes'. One of the failures is due to my timezone, and for some reason Maciej seems to be seeing less failures than me. In addition to these, some tests still hit assertion failures without affecting the results.
Created attachment 20750 [details] Latest results file
The driver script was not properly detecting crashes as failures before. When this was fixed we went up to 86 failures. Now we are down to 61 again.
Created attachment 20786 [details] Latest list of failures I now see 40 regressions, including the one for being in my timezone.
Created attachment 20787 [details] Latest results file
Created attachment 20788 [details] Latest results file Oops. I uploaded the results from my WebKit tree, not my SquirrelFish tree.
All of the remaining test failures are due to the lack of arguments, the lack of a recursion limit, custom valueOf and toString, and getters and setters, except for the following: ecma/Expressions/11.4.1.js ecma_3/Expressions/11.9.6-1.js ecma_3/RegExp/regress-188206.js js1_2/statements/switch2.js js1_5/Array/regress-157652.js js1_5/Regress/regress-118849.js js1_5/Scope/scope-003.js We should try to knock these tests off individually.
ecma/Expressions/11.4.1.js This test fails because "typeof x" throws an exception when x is undefined, but it should return "undefined". This should be an easy fix. Instead of generating this: resolve tr0, x(@id0) type_of tr0, tr0 We should generate something like this: resolve_base tr0, x(@id0) get_prop_id tr0, tr0, x(@id0) type_of tr0, tr0 That does it with no new opcodes, and while the code is a little worse, typeof performance is not critical.
ecma_3/Expressions/11.9.6-1.js fails because this: eval('var x = 0') returns 0 instead of undefined. Probably our codegen for "var" is wrong. Though it would be unfortunate to have to write undefined to a register every time var is executed.
For scope-003 the problem is that closures appear to get the wrong "this" objet in certain cases -- var text = "PASS!!!"; function a() { var text = "FAIL!!!"; function b() { alert(this.text); } this.c = function() { b(); } b(); } new a().c(); -- Should print PASS!!! twice, but it prints FAIL the second time as the activation object is being used as the this object.
In the case of ecma_3/RegExp/regress-188206.js, eval seems to be throwing a syntax error that is uncatchable. In particular, it seems to return the exception instead of throwing it: try { print(eval(' /a**/ ')); } catch (e) { print("error"); }
js1_2/statements/switch2.js seems to be faulty codegen for switch statements without a 'default' block. If no conditions match, we should skip all the case clauses, but instead we fall through to the first. function f2(i) { switch (i) { case 0: case 1: return 1; case 2: return 2; } // with no default, control will fall through return 3; } [ 0] load tr0, 0(@k0) [ 3] stricteq tr0, tr0, lr1 [ 7] jtrue tr0, 21(->30) [ 10] load tr0, 1(@k1) [ 13] stricteq tr0, tr0, lr1 [ 17] jtrue tr0, 11(->30) [ 20] load tr0, 2(@k2) [ 23] stricteq tr0, tr0, lr1 [ 27] jtrue tr0, 6(->35) [ 30] load tr0, 1(@k1) [ 33] ret tr0 [ 35] load tr0, 2(@k2) [ 38] ret tr0 [ 40] load tr0, 3(@k3) [ 43] ret tr0
js1_5/Array/regress-157652.js is the undefined typeof issue again.
ecma_3/RegExp/regress-188206.js as op_new_regex fails to perform an exception check. It should be possible to make this "branchless" relatively trivially.
js1_5/Regress/regress-118849.js appears to fail because of a missing VM_EXCEPTION_CHECK for op_construct, the following does not print "caught" for instance: try { new Function(123,123); } catch(e) { print("caught"); }
I believe we now have all test failures diagnosed. Now we just need to fix the bugs.
I believe the fix for eval("var n = 0; ") returning 0 willsimply be to modify VarStatementNode::emitCode to *not* pass on the dst register (and simliar for constdecl and the comma variants)
We are now down to: ecma_3/Expressions/11.9.6-1.js ecma_3/RegExp/regress-188206.js js1_2/statements/switch2.js js1_5/Regress/regress-118849.js js1_5/Scope/scope-003.js
r32493 broke the following tests: ecma/Expressions/11.8.1.js ecma/Expressions/11.8.2.js ecma/Expressions/11.8.3.js ecma/Expressions/11.8.4.js
We are now down to: ecma_3/RegExp/regress-188206.js js1_2/statements/switch2.js js1_5/Regress/regress-118849.js js1_5/Scope/scope-003.js
All of the individual test failures are now fixed. All of the remaining test failures are due to the lack of arguments, the lack of a recursion limit, custom valueOf and toString, and getters and setters.
The only blocker now is f.arguments / f.caller
All Moz JS tests pass now.