MOZ_ALWAYS_TRUE is only useful for expressions with necessary side effects. The
intent here was to check for this condition even in release builds.
Differential Revision: https://phabricator.services.mozilla.com/D16920
--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
We want to indicate "we didn't actually manage to define your properties as
non-configurable" but we don't want to throw exceptions when people try to
Object.defineProperties with a non-configurable property in the list on a
WindowProxy.
Though maybe we should just silently ignore the "can't define non-configurable
on WindowProxy" bits in defineProperties and just return the object anyway?
The reason we do the "return null" bit in defineProperty is so that Caja and
the like can detect it, but if they're not using defineProperties to start with
they may not need to detect this "failure". On the other hand, Mark Miller
thinks the detection will be needed...
Differential Revision: https://phabricator.services.mozilla.com/D17516
--HG--
extra : moz-landing-system : lando
This adds a new configure option `--enable-wasm-codegen-debug`, which defaults
to true in debug builds (disable otherwise).
It's a first step so as to be able to use this in both the shell and browser,
using the env variables JIT_OPTION_{JitOption field name}.
Differential Revision: https://phabricator.services.mozilla.com/D18341
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
This is pretty straight-forward now and it's much nicer to encapsulate this in
TypeScript instead of having these types-related flags in JSScript.
Differential Revision: https://phabricator.services.mozilla.com/D18550
--HG--
extra : moz-landing-system : lando
As we add more fields to TypeScript (= JitScript in the future), the
AutoSweepTypeScript argument to JSScript::types() is becoming annoying.
This patch moves the argument to TypeScript::typeArray() and
TypeScript::inlinedCompilations() because that's the data affected by type
sweeping.
Differential Revision: https://phabricator.services.mozilla.com/D18549
--HG--
extra : moz-landing-system : lando
Baseline interpreter frames will have a TypeScript/ICScript we want to keep
around on GC.
The JSScript::typesDontCheckGeneration method will be removed in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D18548
--HG--
extra : moz-landing-system : lando
In js::SetPrototype we call GlobalObject::ensureConstructor. I think this is
only a problem for evalcx because other globals have an immutable prototype
chain.
Differential Revision: https://phabricator.services.mozilla.com/D18562
--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
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
Existing code crashes on IonIC frames. Instead, use FrameIter to
determine caller. This also simplifies WASM handling. Also make inJit
use a similar approach for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D18151
--HG--
extra : moz-landing-system : lando
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
