Next batch of spec-compliance and compatibility issues

[Marcus Lagergren]

Great. You are helping us a lot.

Sundar is working on integrating everything you do as unit tests after bugfixing.

Another thing that we might point out at this time is that everything in the "object" package is pretty much implemented according to conform to spec, and just by messing around with the Java in there, I believe there are significant speedups to be achieved in places. We are continuously working to add performance here, so if you see anything that's decidedly suboptimal while going through the builtin object classes, performance fixes are of course also more than welcome ;-) ;-)

(Also, we are hiring :-D)

/M

On Apr 8, 2013, at 10:08 AM, André Bargull <andrebargull at googlemail.com> wrote:

> Hmm, actually this time it was just reviewing the source code and doing experience[1] based testing. For the mentioned ES6 test implementation, I'm using, in addition to the test262 test suite, also the SpiderMonkey test suites [2,3].
> 
> - André
> 
> [1] Rhino and more recently a custom ECMAScript6 test implementation
> [2] http://mxr.mozilla.org/mozilla-central/source/js/src/tests/
> [3] http://mxr.mozilla.org/mozilla-central/source/js/src/jit-test/
> 
> On 4/8/2013 9:41 AM, Marcus Lagergren wrote:
>> You are a champion, André! Keep these tests coming :) If you are using any particular test suite, we would definitely be interested in using it. If you complete a third party contributor's agreement we can help you get OpenJDK credit for fixes that result from this.
>> 
>> Regards
>> Marcus
>> 
>> 
>> On Apr 8, 2013, at 9:33 AM, André Bargull <andrebargull at googlemail.com> wrote:
>> 
>>> Here are some more test cases which don't yet work as expected in Nashorn.
>>> 
>>> - André
>>> 
>>> 
>>> var o = {a:1,b:2,c:3}; for (var x in o) {if (x=='a')delete o.b; print(x)}
>>> => should only print "a" and "b"
>>> 
>>> 9223372036854775807|0
>>> => should return 0
>>> 
>>> 9223372036854775807>>>0
>>> => should return 0 instead of 4294967295
>>> 
>>> Also visible in other places where ToUint32() is used, e.g.
>>> Array.prototype.map.call({length: 9223372036854775807, get 0(){print("get 0")}}, function(){}).length
>>> => should return 0 instead of 4294967295
>>> 
>>> parseInt("10",9223372036854775807)
>>> => should return 10 instead of NaN
>>> 
>>> Array.prototype.map.call({length: -1, get 0(){throw 0}}, function(){}).length
>>> => should throw instead of returning 4294967295
>>> 
>>> parseInt("90071992547409990",10) === 90071992547409990
>>> => should return true
>>> 
>>> escape("\0")
>>> => should return "%00" instead of "%0"
>>> 
>>> "\471".charCodeAt(0)
>>> => should return 39 instead of 313
>>> 
>>> 08in {}
>>> => should throw a syntax error
>>> 
>>> "aa".split(undefined,0).length
>>> => should return 0 instead of 1
>>> 
>>> "aa".split(/(a)/, 1).length
>>> => should return 1 instead of 2
>>> 
>>> "abc".split("", 1).length
>>> => should return 1 instead of 3
>>> 
>>> "aa".split((r = /a/, r.lastIndex = {valueOf:function(){throw 2}}, r))
>>> => should not throw an exception
>>> 
>>> (function(a){ Object.defineProperty(arguments,"0",{get value(){print("get value"); return 0}}); return a })(1)
>>> => should print "get value" only once
>>> 
>>> (function(k){ arguments[0]=1; return k })()
>>> => should return `undefined` instead of `1`
>>> 
>>> (function(k){var a=eval("arguments"); return a[0]})(1)
>>> => should return `1` instead of `undefined`
>>> 
>>> "abc".replace("c", function(){return "$&"})
>>> => should return "a$&c" instead of "abc"
>>> 
>>> 
>>> And some miscellaneous RegExp compatibility issues:
>>> 
>>> /\471/.test("\x271")
>>> => should return true
>>> 
>>> /\08/.test("\x008")
>>> => should return true instead of throwing an exception
>>> 
>>> /\8/.test("\\8")
>>> => should return true instead of false
>>> 
>>> /[]|[^]/.test("a")
>>> => should return true instead of false
>>> 
>>> /(?![])/.test("")
>>> => should return true instead of false
>>> 
>>> /(?=a){2}aa/.test("aaa")
>>> => web compatibility issue (quantifier allowed after positive lookahead)
>>> 
>>> /(?!a){2}bb/.test("bbb")
>>> => web compatibility issue (quantifier allowed after negative lookahead)
>>> 
>>> /(?!(a))(?!\1)b/.test("b")
>>> => returns true but should return false
>>> 
>>> /\cı/.test("\x09")
>>> => should return false instead of true
>>> 
>>> /\cſ/.test("\x13")
>>> => should return false instead of true
>>> 
>>> /[\c0]/.test("\x10")
>>> => should return true instead of false
>>> 
>>> /[\c_]/.test("\x1F")
>>> => should return true instead of false
>>> 
>>> /[\c#]/.test("\\")
>>> => should return true instead of false
>>> 
>>> RegExp("[\0]").test("\0")
>>> => should not throw SyntaxError
>>> 
>>> /[&&]/.test("&")
>>> => should not throw SyntaxError
>>> 
>>> /[[&[]/.test("&")
>>> => should return true instead of false
>>> 
>>> /[ [^]/.test("a")
>>> => should return false instead of true
>>> 
>>> /[^\S\s]/.test(" ")
>>> => should return false instead of true
>>> 
>>> /[\2]/.test("\x02")
>>> => should return true instead of false
>>> 
>>> /[\0-\s]/.test("\x01")
>>> => should throw a SyntaxError (given that /[a-\d]/ also throws a SyntaxError in Nashorn, but compare SpiderMonkey vs. JSC/V8)
>>> 
>>> 
>>> And two more less easy to fix RegExp bugs:
>>> 
>>> /(?:(f)(o)(o)|(b)(a)(r))*/.exec("foobar").toString()
>>> => should return "foobar,,,,b,a,r" instead of "foobar,f,o,o,b,a,r"
>>> 
>>> /(a|b*)*/.exec("aab").toString()
>>> => should return "aab,b" instead of "aab,"
>> 
>