More random details:
Various JIT components required updating for this. In the case of some
methodjit bits, this meant simply disabling those optimizations. This
patch also, passing, improves the Array.prototype.push method's
fast-path to work for any number of provided arguments, not just one.
The patch also fixes a few pre-existing bugs in how array length setting
works and includes the appropriate tests. (If anyone notices, it's
because they were a test in a test suite.) I also added a ParallelArray
test that verifies that arrays with non-writable length function
correctly in parallel code. We bail before getting there now, because
Object.defineProperty isn't parallel-friendly, but if it ever becomes
so, hopefully the test will start failing. Hello, is this thing on?
There are some other uses of ObjectIsNativeWrapper in other scriptable helpers
that are tempting to remove as well, but it's probably just better to wait for
that stuff to just go away. Given that the issue we're running into here is
Window-specific, there's not a pressing need to fix the other stuff.
Right now, it sometimes fills out |desc|, and sometimes just defines the property
on the holder. This can get confusing, so let's refine the semantics here and
describe them in a big comment.
The current setup is just an artifact of how it used to be before I refactored
Xrays. Have it as a virtual trap is more flexible since it allows us to invoke
the right trap by just calling GetXrayTraits(wrapper) from non-templatized code.
Bug 862926 - Generalize the DEBUG code in ParCallToUncompiledScript. r=shu
The old code assumed that the argument `func` will always have a
script associated with it. But this is not true in some cases,
e.g. in the case of ES6 bound functions `(a,b) => ...`.
This patch has two effects:
1. Remove the assumption that the input function has a script. Print
*something* in all cases, regardless of whether we can find a
script or not.
2. For bound functions, attempt to follow the chain of bindings to
find some script at the end of the chain.
1. If one passes a `mode` argument without a property named `mode`,
the previous version will fall into the ThrowError branch
(because mode.mode => undefined and undefined !== "seq")
2. The old error message used the strings "par" and "seq", which might
make the reader think that the assertion is solely about the
appropriate value for the `mode` property, which happens to take on
the values "par" or "seq" in some cases. But the real condition
being signalled here is not about the string values "par" or "seq";
it is instead about the dynamic behavior of the runtime system.
This changes the error message to use longer phrases, which should
hopefully make the intent clearer.
There is a third change I want to make, changing the logic of the
conditional guard further, but that change is not as important to me
as the two above.
