The interpreter engine for the core JavaScript language, independent of the browser's object model. File ONLY core JavaScript language bugs in this category. For bugs involving browser objects such as "window" and "document", use the "DOM" component. For bugs involving calls between JavaScript and C++, use the "XPConnect" component.

(In reply to Eddy Bruel [:ejpbruel] from comment #5)
> > +// 'arguments' in arrow functions nested in other functions
>
> Based on what this test does, this means that arrow functions get their own
> instance of arguments, right? That wasn't clear to me from this comment.
Yes, they do. I improved the comments in several of the tests.
> ::: js/src/jit-test/tests/arrow-functions/strict-1.js
> @@ +10,3 @@
> >
> > +f = (a = {x: 1, x: 2}) => b => { "use strict"; return a.x; };
> > +assertEq(f()(0), 2);
>
> I'm not sure what this tests for. Should the inner => be strict here? What
> about the outer =>? And how does this assertion confirm that?
Yes; no; the fact that it compiles and runs confirms that the outer arrow is non-strict. I only check the return value because why not.
> ::: js/src/jit-test/tests/arrow-functions/strict-2.js
> @@ +2,5 @@
> >
> > load(libdir + "asserts.js");
> >
> > assertThrowsInstanceOf(
> > + () => Function("(a = function (obj) { with (obj) f(); }) => { 'use strict'; }"),
>
> Why do we need the outer () => Function(...) here? I would assume this test
> throws even without that.
Another way to write this test would be:
// |jit-test| error: SyntaxError
(a = function (obj) { with (obj) f(); }) => { "use strict"; };
Using assertThrowsInstanceOf requires putting the test case in quotes and using ()=>Function(...) to parse it on demand. Otherwise the error would be thrown at parse time, before assertThrowsInstanceOf is ever called, so the test would fail.
> ::: js/src/jit-test/tests/arrow-functions/syntax-errors.js
> > + "package => {'use strict';}", // tricky: FutureReservedWord in strict mode code only
>
> How do we make sure that this only throws a syntax error in strict mode? And
> if we don't, could you file a followup bug for this?
Added a test for this (in the same file).