This is a replacement for pn_op that is used in BytecodeEmitter.
This patch just adds the field, but keeps using pn_op.
Part 4 removes the usage of pn_op for FunctionNode.
Differential Revision: https://phabricator.services.mozilla.com/D18328
--HG--
extra : moz-landing-system : lando
CodeNode was shared between ParseNodeKind::Function and ParseNodeKind::Module,
but Module only uses `pn_u.code.body`.
Separated them for further refactoring for function part.
Differential Revision: https://phabricator.services.mozilla.com/D18327
--HG--
extra : moz-landing-system : lando
pn_op for CodeNode can only be JSOP_NOP, JSOP_LAMBDA, and JSOP_LAMBDA_ARROW.
Removed other cases.
Also removed the override with JSOP_FUNWITHPROTO given the field is never read
after the function.
Differential Revision: https://phabricator.services.mozilla.com/D18325
--HG--
extra : moz-landing-system : lando
That will make it detected when we bump the MACOSX_DEPLOYMENT_TARGET
to a value >= 10.12.
Differential Revision: https://phabricator.services.mozilla.com/D18310
--HG--
extra : moz-landing-system : lando
Linearly searching the shape lineage can be expensive. It is going to cause branch misses and cache misses since we are traversing a linked list. Since this is done frequently enough, it may be worth while to "cache" results from the linear search. This revision hopes to lazily allocate a small linear cache after the first linear search on a shape. The results from each linear search afterwards will be placed into the cache. If the jsid that is being searched for is frequently looked up then we obtain a "cache hit" from a quick search in the cache. Otherwise, we fall back to a linear search and append the new entry to the cache. Once the cache is full, it will transform into a shape hash table like the previous approach.
Differential Revision: https://phabricator.services.mozilla.com/D12155
--HG--
extra : moz-landing-system : lando
This is just a VM call in the interpreter. We could optimize this with an IC or
inline path if it ever becomes a problem.
Differential Revision: https://phabricator.services.mozilla.com/D17935
--HG--
extra : moz-landing-system : lando
This adds js::SingletonObjectLiteralOperation and calls it from both the
interpreter and Baseline. The Baseline compiler still has a fast path for the
cloning-not-necessary case.
Differential Revision: https://phabricator.services.mozilla.com/D17934
--HG--
extra : moz-landing-system : lando
The end result we want is that on the web cross-compartment wrappers for
WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true
for both cases that are different-origin (as now) and cases that are
same-origin, since they might become different-origin due to document.domain
changes but we don't want that to affect the wrappers involved.
On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we
would have originSubsumesTarget == targetSubsumesOrigin in all web cases.
I claim that
originSubsumesTarget == targetSubsumesOrigin &&
(!targetSubsumesOrigin ||
(!originCompartmentPrivate->wantXrays &&
!targetCompartmentPrivate->wantXrays)) &&
"object is a WindowProxy or Location"
is a necessary and sufficient condition for using CrossOriginObjectWrapper.
Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin
are both false, then for the WindowProxy and Location cases we currently end up
with the following arguments to SelectWrapper:
securityWrapper: true
xrayType: XrayForDOMObject
waiveXrays: false
So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new
condition keeps doing.
If originSubsumesTarget and targetSubsumesOrigin are both true, then there are
two cases. If both compartments have wantXrays false (which is always the case
on the web), then we end up with the following arguments to SelectWrapper:
securityWrapper: false
xrayType: NotXray
waiveXrays: false
and SelectWrapper returns CrossCompartmentWrapper. We want to do
CrossOriginObjectWrapper instead, as explained above.
Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one
of the compartments has wantXrays set, then we get:
securityWrapper: false
xrayType: XrayForDOMObject
waiveXrays: might be true or false
and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM.
In this case we do _not_ want to start returning CrossOriginObjectWrapper, and
this is a non-web case anyway, since web compartments can't set wantXrays.
Differential Revision: https://phabricator.services.mozilla.com/D18030
--HG--
extra : moz-landing-system : lando
Creating too many SSOs can apparently slow down the debugger and it's just
wasteful.
This patch passes the SSO down to the cloning functions. One nice side-effect is
that the self-hosting SSO code now lives in SelfHosting.cpp instead of JSScript.cpp
Differential Revision: https://phabricator.services.mozilla.com/D18347
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
Existing code didn't handle IonIC frames, but the
FrameScriptIter::script function does the right thing for us here.
Differential Revision: https://phabricator.services.mozilla.com/D18151
--HG--
extra : moz-landing-system : lando
I am not a huge fan of the UnwrapReflectorToISupports setup here. Maybe we
should introduce two differently-named methods that make it somewhat clear what
the limitations of not taking a JSContext are? I couldn't think of sane
naming...
Differential Revision: https://phabricator.services.mozilla.com/D17885
--HG--
extra : moz-landing-system : lando
The basic idea for the changes around UnwrapObjectInternal and its callers
(UnwrapObject, UNWRAP_OBJECT, etc) is to add a parameter to the guts of the
object-unwrapping code in bindings which can be either a JSContext* or nullptr
(statically typed). Then we test which type it is and do either a
CheckedUnwrapDynamic or CheckedUnwrapStatic. Since the type is known at
compile time, there is no actual runtime check; the compiler just emits a call
to the right thing directly (verified by examining the assembly output on
Linux).
The rest of the changes are mostly propagating through that template parameter,
adding static asserts to make sure people don't accidentally pass nullptr while
trying to unwrap to a type that might be a WindowProxy or Location, etc.
There are also some changes to places that were calling CheckedUnwrap directly
to use either the static or dynamic version, as needed.
Differential Revision: https://phabricator.services.mozilla.com/D17883
--HG--
extra : moz-landing-system : lando
This will allow us to correctly handle CheckedUnwrapDynamic on wrappers around
WindowProxy and Location.
Differential Revision: https://phabricator.services.mozilla.com/D17882
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
Eventually this op could use an IC or some frontend/bytecode refactoring to make
it faster in the interpreter. For now following the C++ interpreter is the
simplest solution though.
Differential Revision: https://phabricator.services.mozilla.com/D17939
--HG--
extra : moz-landing-system : lando
Tooru Fujisawa
Mike Hommey
Coroiu Cristina
Sylvestre Ledru
Bogdan Tara
Jon Coppeard
Brindusan Cristian
Denis Palmeiro
Jan de Mooij
Ciure Andrei
Bob Clary
Boris Zbarsky
Daniel Varga
Gurzau Raul
Ted Campbell
Benjamin Bouvier
Robin Templeton
Emanuel Hoogeveen
Csoregi Natalia
André Bargull