I didn't expect to have to specify -o in addition to -O. I get that you might want to use -s instead of -o, but -o is probably much more common.
--HG--
extra : rebase_source : 25e5f6ec23b3b4b006f12d405a30c6c43b631423
I also snuck a change to the output format, to display the test name in the output so that it is possible to associate output with the test that produced it. I mixed it in just because it was a little harder to separate out into a separate patch. I could easily do so, if you'd like.
--HG--
extra : rebase_source : ac26efd171eb6fa19b90eae22a29d047f1ba55b8
The first valid SkipRoot I've found. copyFromArray was inexplicably discarding a handle, and with that fixed there are some unrooted internal pointers stored on the stack. But the only things that can trigger GC will also trigger an early exit, so all of the unrooted pointers are dead if a GC happens anyway.
--HG--
extra : rebase_source : b0c0157bcfdb7461086cdec4be8f71f94ab24c55
Apparently, it was once believed that ToNumber is infallible when given a primitive value. It has 2 or 3 different ways of failing on OOM. For example, if you're onverting a string containing a double, you might blow out memory constructing the dtoa cache.
--HG--
extra : rebase_source : 88c91620678eb9be7ad8dd67f48c54cf843c09e6
We do this for delete_, enumerateNames, and resolveOwnProperty. This doesn't change
existing behavior, because for ProxyXrayTraits and DOMXrayTraits the expando object
will (currently) always be null.
For new DOM proxies, we could probably use the Xray expando machinery for the
regular expando object as well, and free up one of the reserved slots. That's
more than I want to bite off for the moment, though.
I also decided not to block on bug 760095 and just kick the problem of globals
with new binding down the road a little bit.
I'm not sure this stuff is correct for non-WN objects. Hopefully that will
come out in review.
Anyway, with this change, the expando infrastructure in XrayTraits is now
fully generic and non-WN-specific. To make things work for other objects,
we now need to implement the virtual traps and hoist the code that calls the
expando machinery out of XPCWrappedNativeXrayTraits.
It's still WN-only, now we can move the WN-only bits into virtual traps.
Note that the new-binding reparenting code will need to have a call to
CloneExpandoChain.
We don't currently have a good way of selecting the traits used by a given Xray
wrapper. This lets us do that.
Note: We add a call to js::UnwrapObject to GetXrayType while hoisting it. When
it was used only in WrapperFactory, this was unnecessary, because |obj| was
always unwrapped. But for our new purposes, it might not be. Aside from that,
there are no changes to the function.
With this patch, all holders are created lazily. There are two common accessors,
getHolder() and ensureHolder(). The former returns null if no holder exists, the
latter lazily creates the holder if it doesn't exist. It does this by calling into
a virtual trap on XrayTraits, which lets the appropriate Xray type do its thing.
The current name potentially implies that the object returned is an inner
object in the JS sense, which isn't true. Really we just want the thing
we're Xraying to.
There's some code that can be shared between different Xray traits, but can't
(yet) be hoisted into XrayWrapper, because it needs to be callable from outside
XrayWrapper where we don't have the appropriate template parameters. Moreover,
this code benefits from virtual function specialization. The use case here is
illuminated in the next patch.
For the moment, we skip converting the bulk of the traits calls to virtual
methods, because they're working just fine.
We might as well do this dynamically, which simplifies the code. Note that we
could avoid the reserved slot by parenting the holder to the wrapper. But the
JS parent API is deprecated, and we need to move away from it to reserved slots
anyhow. We might as well start here, with the added advantage that parenting
to the global makes us consistent with the other Xray types.
