This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This implements the special clearKeptObjects() function for the browser and turns on the pref to allow the tests to run.
Differential Revision: https://phabricator.services.mozilla.com/D63193
--HG--
extra : moz-landing-system : lando
Added assertion and removed unnecessary (and incorrect) use of this via ObjectGroup's finalizer.
Differential Revision: https://phabricator.services.mozilla.com/D63188
--HG--
extra : moz-landing-system : lando
For now this is Nightly-only so that IsTypeInferenceEnabled() shouldn't
impact performance for our non-Nightly users.
Depends on D63143
Differential Revision: https://phabricator.services.mozilla.com/D63145
--HG--
extra : moz-landing-system : lando
Also fix the getWaitForAllPromise testing function to not use IsPackedArray
because that depends on type information and caused test failures.
Differential Revision: https://phabricator.services.mozilla.com/D63143
--HG--
extra : moz-landing-system : lando
Unlike stack type monitoring, heap TI is much harder to disable completely
because it's intertwined with a lot of other things. This patch does the
following:
* Don't track type information for any ObjectGroups (in ObjectGroupRealm::makeGroup).
* Turn off heuristics for singletons, allocation-site groups, function groups.
* Turn off type update ICs in Baseline.
* Add early returns to some hot functions.
Depends on D63140
Differential Revision: https://phabricator.services.mozilla.com/D63141
--HG--
extra : moz-landing-system : lando
If TI is disabled we don't allocate any StackTypeSets in JitScript and we don't
allocate/use type monitor ICs.
Differential Revision: https://phabricator.services.mozilla.com/D63140
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
When structured clone reads a SAB and creates a new SAB object, or
when it serializes a SAB onto a channel, call a callback that lets the
embedder know. The embedder can then adjust its policy. Concretely,
we want to allow the browser to serialize threads in a process that
uses JS shared memory.
Note, for WebAssembly.Memory, reading and writing are delegated to the
cloning operations for SAB, so no special handling is needed.
Differential Revision: https://phabricator.services.mozilla.com/D61455
--HG--
extra : moz-landing-system : lando
We do not want explicitly-returned completion values to cause later hooks
to be skipped, because consumers of the Debugger API need to be confident that
their code will not be silently skipped because some entirely unrelated
code instructed the debuggee to throw/return/terminate.
Differential Revision: https://phabricator.services.mozilla.com/D58187
--HG--
extra : moz-landing-system : lando
We want each hook to run in sequence, and we do not want the failure of one
hook to cause later hooks to skip execution. Doing so would make it difficult
for consumers of the Debugger API to be confident that their hooks will be
consistently executed, since entirely independent code could otherwise cause
their logic to be silently skipped.
Differential Revision: https://phabricator.services.mozilla.com/D58186
--HG--
extra : moz-landing-system : lando
Our goal is to guarantee that each hook observes the same state of the
debuggee itself unless explicit action is taken to change debugee state.
By passing this value along as we have been doing until now, we make it
impossible for later hooks to see the actual return value that the debuggee
code returned, which could be quite frustrating for debugger.
Differential Revision: https://phabricator.services.mozilla.com/D58185
--HG--
extra : moz-landing-system : lando
Just a quick cleanup. There's no reason for this value to be pulled into the
completion and then back out again right away. It is much simplier to access
the generator directly.
Differential Revision: https://phabricator.services.mozilla.com/D58182
--HG--
extra : moz-landing-system : lando
Switching the hook-dispatching logic to use the common bool-returning result
value allows us to easily centralize error reporting and debugger-realm-enter
such that we don't need to worry so much about how the error is handled.
Differential Revision: https://phabricator.services.mozilla.com/D57938
--HG--
extra : moz-landing-system : lando
Moving the location that the values are wrapped allows us to remove the need
for Maybe<AutoRealm> in favor of a normal RAII AutoRealm, which makes it much
easier to follow what realm is currently active.
Differential Revision: https://phabricator.services.mozilla.com/D57932
--HG--
extra : moz-landing-system : lando
This changes processHandlerResult to use the common bool-returning approach
used elsewhere in the codebase, which helps to simplify a lot of the code
because we can cleanly separate errors from explicitly-requested ResumeMode
values.
Differential Revision: https://phabricator.services.mozilla.com/D57931
--HG--
extra : moz-landing-system : lando
This avoids duplicating logic between processParsedHandlerResult and
processHandlerResult since both are quite similar.
Differential Revision: https://phabricator.services.mozilla.com/D57930
--HG--
extra : moz-landing-system : lando
Merging these the logic to fetch the `this` value and validate it into the same
function makes all of this code much more readable. We get to keep the frame
and pc values as a neater pair this way, and avoid needing a hard-to-follow
Maybe<T> value propagating through our functions.
Differential Revision: https://phabricator.services.mozilla.com/D57929
--HG--
extra : moz-landing-system : lando
These changes make fireNativeCall and fireExceptionUnwind more consistent
by removing logic from them that doesn't really need to happen per-debugger.
It is also logic that breaks if the the fireXX functions are called after
the AutoRealm moved us into the debugger compartment, which is something
we'll be doing later to centralize more of the hook dispatch logic.
Differential Revision: https://phabricator.services.mozilla.com/D60808
--HG--
extra : moz-landing-system : lando
We move adjustment of the return value until the very last step before applying
the value itself, because it is important that any adjustments performed take
place while inside the debuggee's context, and most importantly in the
context of this but, inside the debuggee's microtask queue.
AutoDebuggerJobQueueInterruption swaps out the microtask queue for one
specific to the debugger, and this bug happened because we were queuing
debuggee promise jobs in the debugger's microtask queue.
Differential Revision: https://phabricator.services.mozilla.com/D57727
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
The default method implementations cause problems when trying to
override them with different types in a direct call class.
For the `Recv__delete__` case there's a simple solution: omit it if
there are any arguments, because it doesn't make much sense to specify
arguments and then completely ignore them, and the no-arg case isn't a
problem for overriding.
Differential Revision: https://phabricator.services.mozilla.com/D62977
--HG--
extra : moz-landing-system : lando
Baseline code has explicit pre- and post-write barriers, but for Ion we should be
able to reuse the existing `MPostWriteBarrier`. Only pre-write barriers require
an explicit MacroAssembler call when emitting the assembly code.
Differential Revision: https://phabricator.services.mozilla.com/D58787
--HG--
extra : moz-landing-system : lando
Passes the target `JSFunction` through to `patchInlinedReturn`, so we don't
emit `MReturnFromCtor` for derived class constructors. (Using `MReturnFromCtor`
for derived class constructors leads to repeated bailouts, because the computed
this-value is a magic type, which isn't a valid return type for `MReturnFromCtor`.)
Differential Revision: https://phabricator.services.mozilla.com/D58785
--HG--
extra : moz-landing-system : lando
The note in `IonBuilder::inspectOpcode()` doesn't seem to apply anymore, probably
when we switched to CacheIR for call opcodes, the bailout issue noted there
doesn't matter anymore.
Inlining derived class constructors is enabled in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D58784
--HG--
extra : moz-landing-system : lando
Includes support for `foldsTo`, so we can optimise away the instruction for
known types.
Differential Revision: https://phabricator.services.mozilla.com/D58781
--HG--
extra : moz-landing-system : lando
Changes the already present `MCheckReturn` class to match the baseline
implementation. `MCheckReturn::foldsTo` didn't fold away known types, so some
basic folding was directly added to `IonBuilder::jsop_checkreturn()`.
Differential Revision: https://phabricator.services.mozilla.com/D58780
--HG--
extra : moz-landing-system : lando
