Split out from bug 805052, item 14: XrayAwareCalleeGlobal uses the parent of the function to get to the Xray the function came from. Maybe we can use a reserved slot here too.

Comment on attachment 8573966 [details] [diff] [review] Part 2 updated with more asserts Review of attachment 8573966 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/xpconnect/wrappers/XrayWrapper.cpp @@ +126,5 @@ > + } > + > + // The functions we expect here have the Xray wrapper they're associated with > + // in their XRAY_DOM_FUNCTION_PARENT_WRAPPER_SLOT and, in a debug build, their > + // JSNAtive in their XRAY_DOM_FUNCTION_NATIVE_SLOT_FOR_ASSERT. Assert that JSNative

Backed out for assertion failures: https://hg.mozilla.org/integration/mozilla-inbound/rev/dc86a4e16519

OK, so... Looks like a JSNative pointer can have the low bit set in some cases (though apparently not on Mac on my machine?) so can't be stored in a PrivateValue. Peter, I'm going to switch to storing the function object itself and hoping that no one else would do such a silly thing.

Relanded with that change: https://hg.mozilla.org/integration/mozilla-inbound/rev/94a0946d5a0a https://hg.mozilla.org/integration/mozilla-inbound/rev/fdb146bc4052

https://hg.mozilla.org/mozilla-central/rev/94a0946d5a0a https://hg.mozilla.org/mozilla-central/rev/fdb146bc4052