When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
This is just a bit of cleanup I'd noticed while writing new implementations of these.
Differential Revision: https://phabricator.services.mozilla.com/D17659
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
This is just a bit of cleanup I'd noticed while writing new implementations of these.
Differential Revision: https://phabricator.services.mozilla.com/D17659
--HG--
extra : moz-landing-system : lando
I added ARM64_WIN64 to every line that mentioned X86_WIN32 and X86_WIN64.
This makes sure the allocation routines do the proper VirtualProtect on the trampolines.
Differential Revision: https://phabricator.services.mozilla.com/D19567
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
Problem: When a stack chunk had to be popped as part of a control flow
instruction, the amount to pop was not always computed as a multiple
of ChunkSize. The reason is that the fixed amount of stack that
should not be popped isn't necessarily a multiple of ChunkSize, yet
this was assumed.
A small adjustment to the calculation fixes that.
Also added an assertion that would have caught this problem more
easily.
Also did some desirable drive-by fixes to clarify documentation and to
factor the resulting code.
The TC sets up a situation where we require a chunk to be created and
then destroyed in the 'else' arm of the 'if', at the same time as the
fixed amount of stack is not a multiple of ChunkSize.
Differential Revision: https://phabricator.services.mozilla.com/D19470
--HG--
extra : rebase_source : 08e8bde715995babd535d73c691335be9fef983a
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
This is just a bit of cleanup I'd noticed while writing new implementations of these.
Differential Revision: https://phabricator.services.mozilla.com/D17659
--HG--
extra : moz-landing-system : lando
With these changes, XBL just runs in the window scope of whatever document it's
attached to. Since (outside of tests and "remote XUL") we no longer attach XBL
to web documents, this is fine. And "remote XUL" already ran without the XBL
scope.
Native anonymous content, which used to be placed in the XBL scope to hide it
from the page, is now placed in the unprivileged junk scope, so it stays hidden
from the page.
dom/xbl/test/test_bug944407.xul is being removed because we are changing the
behavior it's trying to test for. Since we now always put the XBL in the same
scope as the page, script is enabled for the XBL if and only if it's enabled for
the page.
dom/base/test/test_bug419527.xhtml, dom/events/test/test_bug391568.xhtml,
dom/xbl/test/test_bug1086996.xhtml are being switched to a chrome test because
otherwise the XBL can't see the getAnonymousNodes method.
All the XBL bits are being removed from test_interfaces because we no longer
have a separate XBL scope to test the behavior of.
js/xpconnect/tests/mochitest/test_nac.xhtml is being removed because XBL no
longer has access to NAC unless the page it's attached to does too, so the test
doesn't really make sense.
layout/xul/test/test_bug1197913.xul is being switched to a chrome test because
its XUL elements use bindings that rely on APIs that are not exposed to normal
web content.
layout/reftests/bugs/495385-2f.xhtml is being removed because I can't think of
a sane way to test that in the new world, short of running the reftest as
chrome. And it doesn't seem worthwhile to look for a way to do that.
dom/xbl/test/test_bug1098628_throw_from_construct.xhtml now needs to
expectUncaughtException(), because the exception is now being thrown in Window
scope.
dom/xbl/test/test_bug1359859.xhtml needs to expectUncaughtException() as needed
and not use XPCNativeWrapper (which it doesn't need to anyway now).
dom/xbl/test/test_bug389322.xhtml, dom/xbl/test/test_bug400705.xhtml,
dom/xbl/test/test_bug401907.xhtml, dom/xbl/test/test_bug403162.xhtml,
dom/xbl/test/test_bug526178.xhtml, dom/xbl/test/test_bug639338.xhtml don't need
to use XPCNativeWrapper anymore.
dom/xbl/test/test_bug821850.html is being removed because it exists only to test XBL scopes.
dom/xbl/test/file_bug950909.xml is being changed to work without a separate XBL
scope (though whether the test still makes sense at that point is a bit questionable).
Differential Revision: https://phabricator.services.mozilla.com/D19260
--HG--
extra : moz-landing-system : lando
In the new setup, they are still same-compartment with their target, but may
not be same-realm (due to transplants).
We could make them be same-realm by adjusting FixWaiverAfterTransplant, but
this is conceptually simpler.
Differential Revision: https://phabricator.services.mozilla.com/D19261
--HG--
extra : moz-landing-system : lando
This moves the allocation of the ScriptSource object into
ScriptSource::XDR instead of being done in the caller. A
MutableHandle<ScriptSourceHolder> is used to manage both
ScriptSource::refCount as well as tracing Atoms from BinAST.
Differential Revision: https://phabricator.services.mozilla.com/D19164
--HG--
extra : moz-landing-system : lando
Make the method static so that in a follow-up the allocation of the
object can be absorbed in the method.
Differential Revision: https://phabricator.services.mozilla.com/D19163
--HG--
extra : moz-landing-system : lando
Also change JSTryNote::kind to uint32_t to absorb alignment padding of
structure.
Differential Revision: https://phabricator.services.mozilla.com/D19007
--HG--
extra : moz-landing-system : lando
There is no existing bug, but passing correct values to constructor is
more predictable for future.
Differential Revision: https://phabricator.services.mozilla.com/D18875
--HG--
extra : moz-landing-system : lando
This ensures the script source is properly ininitialized before calling
JSScript::Create. This fixes issues with LCov when the script comes from
an XDR-based cache.
Differential Revision: https://phabricator.services.mozilla.com/D18874
--HG--
extra : moz-landing-system : lando
Sanity check was reading out-of-range value. This caused more XDR decode
failures than expected, but non-cache load would recover anyways. With
fix, a few more cases will support XDR caching.
Differential Revision: https://phabricator.services.mozilla.com/D18873
--HG--
extra : moz-landing-system : lando