Next batch of spec-compliance and compatibility issues

[André Bargull]

And some bugs in JSONFunctions.

typeof JSON.parse('{}',function(){})
=> expected "undefined" instead of "object"
=> JSONFunctions#walk() looks a bit wrong.

Object.defineProperty(Object.prototype,"",{set: 
function(v){print("called set")}})
JSON.parse('{}',function(){})
=> should not call the setter (use [[DefineOwnProperty]] instead of [[Put]])

Object.defineProperty(Object.prototype,"foo",{set: 
function(v){print("called set")}})
JSON.parse('{"foo": 1}')
=> should not call the setter (use [[DefineOwnProperty]] instead of [[Put]])


On 4/8/2013 11:28 AM, André Bargull wrote:
> Instead of performance tips, some more bugs in NativeArray ;-)
>
> - André
>
>
> Object.defineProperty([],"length",{writable:false}).push(0)
> => should throw an exception (strict = true!)
>
> Object.defineProperty([],"length",{writable:false}).pop()
> => should throw an exception (strict = true!)
>
> Object.defineProperty([,,],"0",{writable:false}).reverse()
> => should throw an exception (strict = true!)
>
> Object.defineProperty([],"length",{writable:false}).shift()
> => should throw an exception (strict = true!)
>
> Array.prototype.sort() also calls ScriptObject#isStrictContext(), but 
> implementations are allowed to use a custom behaviour if array index 
> properties are non-writable/non-configurable. Nevertheless, I'd still 
> remove isStrictContext() from this method...
>
> Object.defineProperty([],"length",{writable:false}).splice(0)
> => should throw an exception (strict = true!)
>
> Object.defineProperty([],"length",{writable:false}).unshift()
> => should throw an exception (strict = true!)
>
> [].concat([,]).hasOwnProperty("0")
> => should return false instead of true
>
> a = []; a[0x7fffffff]=1; a.sort()[0]
> => should return 1 instead of undefined
> (Unchecked conversion from long to int also present in 
> NativeArray#splice() and NativeArray#slice())
>
> [2,1].sort(null)
> => should throw an exception (comparefn != undefined && not callable)
>
> [2,1].sort(function(x,y){return x<y?-Infinity:x>y?Infinity:0})+""
> => should return "1,2" instead of "2,1"
>
>
>
> On 4/8/2013 10:15 AM, Marcus Lagergren wrote:
>> 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,"
>>
>