We rewrote SpiderMonkey's split implementation to be more ES5 compliant. This introduced some new test failures which I believe are invalid.
Some tests assume an |undefined| separator should be treated as the string "undefined". This is invalid per ES5 15.5.4.14 step 10.
- S15.5.4.14_A2_T7
- S15.5.4.14_A1_T8
- S15.5.4.14_A1_T6
- S15.5.4.14_A1_T7
- S15.5.4.14_A1_T9
Another test calls split with |undefined| this value. This is invalid per ES5 15.5.4.14 step 1 (CheckObjectCoercible throws a TypeError if |this| is undefined)
- S15.5.4.14_A1_T3
Agreed on S15.5.4.14_A1_T6 through S15.5.4.14_A1_T8. According to ES5.1 (15.5.4.14 prologue):
If separator is undefined, then the result array contains just one String, which is the this value (converted to a String).
Step 10 implements this behavior.
There does seem to be a minor spec issue though: Step 8 of 15.5.4.14 does weakly indicate that the 'R' used in the algorithm will in fact be the string "undefined" though.
As for S15.5.4.14_A1_T9, could you offer an explanation as to why this is invalid? Step 10 definitely doesn't apply and it should sail through Step 1.
Finally, I completely agree on S15.5.4.14_A1_T3. Will be disabling everything except S15.5.4.14_A1_T9 in Hg shortly. If you can provide a justification for this as well, I'll disable it too.
Thanks for looking at this.
The result of step 8 is assigned to R and step 10 looks at the original, unmodified |separator| argument, but I agree that it would've been clearer if step 10 came before step 8.
S15.5.4.14_A1_T9 check 3 does something like this:
assert(new String(some_object).split(function(){}()).length === 2);
As far as I see this does go through step 10 because separator is undefined?
I've been looking at the individual test262 tests to figure out what's up with all of them, and these three, mentioned in this bug, are still apparently-buggy tests:
S15.5.4.14_A1_T6 Argument is x, and instance is new String. x is undefined variable fail
S15.5.4.14_A1_T9 Argument is function(){}(), and instance is String(object), object have overrided toString and valueOf functions fail
S15.5.4.14_A2_T7 Call split(void 0), instance is "thisundefinedisundefinedaundefinedstringundefinedobject" fail
Any chance of disabling them soon, or of modifying them to be correct?
Sorry for the delay. There were two typos that prevented S15.5.4.14_A1_T6 and S15.5.4.14_A2_T7 from being disabled, and I just hadn't gotten back to S15.5.4.14_A1_T9 yet. Disabled all three in Hg now, and these will make it to the live website with the next minor update (sometime this week?).
Sounds good, thanks.
I've fixed the assertions in:
- S15.5.4.14_A1_T6
- S15.5.4.14_A1_T7
- S15.5.4.14_A1_T8
- S15.5.4.14_A2_T7
For, S15.5.4.14_A1_T3, I bound the 'split' function to the global object and did something similar for 'toString' => this is now valid as well.
Your explanation on S15.5.4.14_A1_T9 makes sense (didn't notice the second '()' in 'function(){}()' when I commented on this previously. Fixed.