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
<[email protected]> 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
<[email protected]> 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,"
