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
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.
Depends on D17934
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.
Depends on D17645
Differential Revision: https://phabricator.services.mozilla.com/D17934
--HG--
extra : moz-landing-system : lando
Remove all(*) uses of ScratchDoubleReg / ScratchFloat32Reg in common
code and tier-1 macro-assemblers, and use ScratchDoubleScope /
ScratchFloat32Scope exclusively. This sometimes leads to a very minor
amount of extra code, but ensures that we do not reuse a live
register.
(*) There are a couple of uses left, but these only check that the
scratch regs aren't used where they can't be used or check whether the
scratch regs need to be saved and restored across a call to external
code.
--HG--
extra : rebase_source : 9113a93e4d9a63c17257329302f9d648b7cf7298
extra : amend_source : b6b234553602713032ca034e6d11fa1942a3ca17
`OffThreadPromiseRuntimeState::internalDrain` assumes that if
`internalDispatchQueue_` is empty but `live_` is not, then there must be
`OffThreadPromiseTasks` still in flight that it should block for. To support
reentrant calls to `internalDrain`, we need to make two changes:
- First, `internalDrain` needs to dequeue jobs one at a time, rather than
swapping out the entire queue, which makes the queue look empty when there are
still jobs yet to be run.
- Second, `OffThreadPromiseTask::run` needs to remove each task from `live_`
*before* calling its `resolve` method, so that if the last task in the queue
reenters `internalDrain`, that won't mistake the final entry in `live_` for
something it must block on.
Since there are still `OffThreadPromiseTasks` that get registered in `live_`
but then get destructed without being run (for example, in `WasmJS.cpp`'s
`ResolveResponse_OnFulfilled`), we cannot assume that the `run` method will
unregister all tasks; the destructor still needs to check if unregistration is
necessary. So we factor out unregistration into its own method.
Differential Revision: https://phabricator.services.mozilla.com/D17704
--HG--
extra : moz-landing-system : lando
To support reentrant calls to OffThreadPromiseRuntimeState::internalDrain, we
need to be able to tell reliably whether the queue is empty or not. The present
implementation tactic of using a Vector to represent the queue, pushing new jobs
onto the end, and then stealing the entire vector and processing all the jobs in
one pass over its make it appear that the queue is empty when, in fact, there
remain jobs that have not yet been run.
Since we have a true FIFO type ready at hand, we can use that to give the
off-thread promise machinery a more traditional implementation that dequeues one
job at a time.
Differential Revision: https://phabricator.services.mozilla.com/D17702
--HG--
extra : moz-landing-system : lando
It relies on AC_TRY_RUN, which doesn't work on cross-compiles. What this
means is that the feature has been disabled on mac builds on automation
ever since we switched to cross-compiles. It's still enabled on local
mac builds because the test runs there, and returns "yes". It also means
it's disabled on Android, where it probably works (at least debug tests
on try don't complain).
It also doesn't currently run on Windows because it's in a skipped
section on Windows, but if moved out of that section, the test returns
"no".
So, we remove any configure test for the feature, in favor of
preprocessor checks in nsTraceRefcnt.cpp.
Depends on D18055
Differential Revision: https://phabricator.services.mozilla.com/D18056
--HG--
extra : moz-landing-system : lando
Autoconf 2.13 documentation says: "If the memcmp function is not
available, or does not work on 8-bit data (like the one on SunOS 4.1.3),
add `memcmp.o' to output variable LIBOBJS."
The documentation of more recent versions of autoconf also mention NeXT
x86 OpenStep, and say "This macro is obsolescent, as current systems
have a working memcmp. New programs need not use this macro."
We're also not using LIBOBJS, so, even if somehow some machine had the
test detect something weird going on, the result of the test wouldn't
have an effect on the build anyways.
Apart from that, it's also one of the few tests that relies on actually
running a compiled binary during configure, which requires some
autoconf-specific definition of cross-compilation (where --target=i686
--host=x86_64 is not cross-compilation), and we're better off getting
rid of such tests completely.
Depends on D18054
Differential Revision: https://phabricator.services.mozilla.com/D18055
--HG--
extra : moz-landing-system : lando
Daniel Varga
Boris Zbarsky
Bogdan Tara
Gurzau Raul
Ted Campbell
Ciure Andrei
Benjamin Bouvier
Robin Templeton
Csoregi Natalia
André Bargull
Jan de Mooij
Lars T Hansen
shindli
Razvan Maries
Ms2ger
Steve Fink
Nicolas B. Pierron
Jim Blandy
Tooru Fujisawa
Mike Hommey