* Introduce a setZone method that changes the zone and the freelist.
* leaveAtomsZone() private
--HG--
extra : rebase_source : 1da68a20211b410b651a4d12548f09b3b942b017
This gcc 4.8.5 workaround (from bug 1316850) is no longer needed because Firefox currently requires gcc 6.1 or later (as of bug 1444274).
MozReview-Commit-ID: 4JFmOYoJnMH
--HG--
extra : rebase_source : f348a629f25f6852250306d969262372460a677a
extra : source : cb42b2192694148ffdf97c3a5c2fabb2578a0ec0
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : 1702e63fed719fc92def2bdbbb8a7c53572432db
extra : source : 41bedc526dd6ec6b7e8c7be1c832ac60c81d6263
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : c528dffe3a54eec75ad6cb358980b783b00eb4a4
The problem we're solving here: getting/entering the realm/global of a cross-compartment wrapper doesn't make sense once there are multiple realms in a compartment and the CCW will be shared by all of them. Because nsXPCWrappedJS can store a CCW, we will no longer be able to use this JSObject to enter the target realm.
What this patch does: we pass a JSContext* to nsXPCWrappedJS::GetNewOrUsed and we use this to store a global object in nsXPCWrappedJS (with the invariant that the object and global stored in nsXPCWrappedJS are same-compartment). Then when we want to enter the nsXPCWrappedJS's target realm, we use this global object instead of the maybe-CCW object. Because we currently still have one realm per compartment and the objects are same-compartment, this is guaranteed to preserve behavior for now.
nsXPCWrappedJS has some code to deal with weak pointers. Fortunately this applies only to root wrappers and root wrappers always store an unwrapped JSObject, so the extra global we store is guaranteed to be marked by the GC in that case (a global object is never collected when there are live JSObjects belonging to the same realm).
Because it's quite strange, badly named, not that useful, and barely used.
Also remove WeakMap::lookupWithDefault(), which is similar, but not used at
all.
MozReview-Commit-ID: IhIl4hQ73U1
--HG--
extra : rebase_source : 7da237a56391836ca5d056248f18bd5e2d8b1564
Because (a) it's kinda weird, and (b) only used in a single test, where it can
be easily replaced with a vanilla add().
MozReview-Commit-ID: L4RoxFb7yGG
--HG--
extra : rebase_source : 515a5ede5d417686907345ad9069c6a41669dd17
It's identical to mozilla::CStringHasher.
Also fix a comment at the top of HashTable.h about CStringHasher.
--HG--
extra : rebase_source : 92176c4f6ea8041f309764b4ce0271a494853a7b
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
Summary:
DestructValue acts a lot like CleanupValue, however in addition to normal
cleanup work, it invokes the destructor of complex data types. This is important
to ensure that constructors and destructors are matched for these complex data
types.
CleanupValue is also used to clean up a value without destructing it, so cannot
be modified in-place.
Depends On D2689
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2690
Summary:
This macro simplifies code which allows performing an operation on or
extracting information from a particular nsXPTType's native representation.
It is also used in part 2 to implement xpc::DestructValue.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2689
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
TypedObjects that map Wasm structs with fields that have Ref type are
not yet constructible from JS because the type constraint can't be
honored. So for now, make it possible for Wasm to flag such structs
as unconstructible-from-JS.
--HG--
extra : rebase_source : aab9d7f2ba7b4c1ff7875d184b86bb0ae3e32413
extra : intermediate-source : 97c72ae6e843fe1cb712bd4855d174fc711c3cb0
extra : source : f59588ebc5c4ff06bfb437896147e07cb856e355
This allows internal clients (notably Wasm) to flag TO fields as
immutable; we need this both to provide immutability for fields that
are declared immutable in wasm structs, and to temporarily avoid the
need for type constraints on assignments to Ref-typed pointer fields.
--HG--
extra : rebase_source : 19d1b1bf81396ca305b699cda0277fd8e41f5fe9
extra : intermediate-source : d219c9587f920a0f5924dbdab3e8cf5dfecf3f75
extra : source : f1161dd31ac1cf6f050315d04b978b9d6c0c824a
Struct types need to appear to be callable, or some paths through the
engine will not think that they are constructors (since constructors
are callable).
They are not *actually* callable however; the call implementation
always throws.
--HG--
extra : rebase_source : a0db93050943bda3348887c8a63a374e19158d41
extra : source : 437198f32338d69602f3375f94a996f3d880fa17
In the old days we could only share a SharedArrayBuffer, but now we
can also share WasmMemory and WasmModule objects. Rename the shell's
get/setSharedArrayBuffer as get/setSharedObject and generalize them to
handle the new types.
Leave the old names in place as aliases of the new names.
We rename /some/ uses of get/setSharedArrayBuffer in existing test
cases, but leave uses in test262 alone; we need to upstream those more
carefully.
--HG--
extra : rebase_source : 5ca04306a739249a70fc4aa8734b08e16d62f7d4
extra : source : fcd471c23cf3c1374541df766fd5aea0628fb2a5