This compartment flag was only ever needed in order to track system-privileged
add-on code running under the compartment-per-addon system. That system, and
the legacy add-ons it supported, are gone.
WebExtension compartments have their add-on ID stored on their principal, and
are tracked in less obtrusive ways, so this code is no longer useful.
MozReview-Commit-ID: NVEd3Oawak
--HG--
extra : rebase_source : 31908a4daa5e7897ce165a5383110fb722391662
The path service was created to allow us to track resources that were part of
legacy add-ons, and to map URIs ponting to those resources to add-on IDs, so
that we could apply special behavior to them.
We have better ways to track resources belonging to WebExtensions, so this
code does not benefit them in any significant way.
The only remaining legacy extensions are system add-ons, which we control, and
do not need the path service in order to track.
MozReview-Commit-ID: BKXkcaM7jJx
--HG--
extra : rebase_source : c8cb0f7cec919b767bbcfe5433a6838523747676
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
This is all dead code now that the add-on manager support for shimmed add-ons
has been removed.
MozReview-Commit-ID: J6aRQDqEahs
--HG--
extra : rebase_source : 406d65b2a0be6340df6c28f42b38bd8a47b96b77
If RegExp.cpp and String.cpp are unified, we bust the build. This
removes the spurious namespace from RegExp and uses explicit :: global
namespace for String.cpp where cares about the difference between :: and
js::unified.
MozReview-Commit-ID: HGJOvQyzrWK
--HG--
extra : rebase_source : 7d10137730cc661beb2b6d470d03563a0df3792a
This isn't needed since Console is an interface and not an object
MozReview-Commit-ID: ZoIo2TS9QL
--HG--
extra : rebase_source : 7ccb86dd4290e5d7ac829cab6dcf2f9548d89f11
We use a wrapper script when compiling with MSVC to parse the
/showIncludes output and thereby generate a Makefile dependency
fragment. This fragment enables us to do correct and faster incremental
builds. But the cost of invoking the wrapper script can be significant;
it's an extra process or two to launch for every single compilation.
Instead, let's have clang-cl generate the dependencies directly, which
should be somewhat faster.
As the SP is weird on ARM64 a number of adjustments must be made to
the stubs code. On the one hand we never have to check for stack
alignment; on the other hand we don't get to use raw Push and Pop to
manipulate the stack, the word-aligned stack in the JIT ABI requires
some unusual adjustments, and the fact that the JIT treats x28 (the
PseudoStackPointer) as non-volatile requires it to be saved and
restored, or recomputed.
On ARM64 we do not have a pop-return-address-from-memory-and-return,
and this causes a slight problem for the interrupt stub code. On MIPS
this is fixed by using HeapPtr as a temp for the return address and
then restoring HeapPtr in the branch delay slot, but ARM64 does not
have branch delay slots either.
For now I'm using x28 to hold the return address since Wasm code does
not use x28 (it is not allocatable even in wasm code at this point)
and the interrupt stub only runs when the machine is in the wasm
state. If this turns out not to be workable we probably need to
reserve another register just for this.
--HG--
extra : rebase_source : bc6f809305fdb8713cd93170ec434ae1d8e64243