Use the same jitCodeRaw fallback strategy that visitKnownCall does to handle
potential lazy clones. We also stop allowing natives to flow into the
no-args-check case to avoid needing to guard against them.
Depends on D58097
Differential Revision: https://phabricator.services.mozilla.com/D58098
--HG--
extra : moz-landing-system : lando
When IonMonkey uses the no-arg-check entry point, we may still see lazy
function clones. In this case the no-arg-check entry point is unavailable,
but we can still fallback to the standard jitCodeRaw. This patch factors this
fallback behaviour out of visitCallKnown.
The new version guards the warmUpData tag bits instead of loading the
function flags. This makes it compatible with removing the INTERPRETED_LAZY
flag. In the future, the fallback case will no longer be necesarry once
delazification reuses the same script and all function clones delazify at
same time as their canonical one does.
Depends on D58096
Differential Revision: https://phabricator.services.mozilla.com/D58097
--HG--
extra : moz-landing-system : lando
Group the jitCodeRaw handling so it becomes simpler. By changing the scratch
register used by switchToObjectRealm we can move it later in code.
Differential Revision: https://phabricator.services.mozilla.com/D58096
--HG--
extra : moz-landing-system : lando
Showing a new notification with the same name of an existing notification
replaces the old notification so we must unregister it from Windows at that
point.
Differential Revision: https://phabricator.services.mozilla.com/D58270
--HG--
extra : moz-landing-system : lando
Other platforms send out the finished notification when the notification is
programmatically cancelled. This patch ensures that finished is always sent.
Differential Revision: https://phabricator.services.mozilla.com/D58269
--HG--
extra : moz-landing-system : lando
It will be relanded once these are complete. This prevents from those tasks
getting scheduled for every push until the initial ones have been completed.
This patch implements one half of support for multi-value returns in the
baseline compiler.
The idea is that when you have a function that has stack return values,
it will receive an additional synthetic argument: a pointer to the stack
results area. The layout of this area is the same as that understood by
BaseCompiler::pushBlockResults.
When compiling a function that has stack results, the stack result area
pointer will come in either in a register or on the stack. If it's on
the stack we record that offset and will load a pointer at that offset
when returning values. If the pointer is in a register, it gets spilled
to the stack after the spilled copies of previous register arguments.
When calling a function that has multiple return values, we bump the
stack pointer and pass an additional argument to the callee: the pointer
to that stack area. After the call, in the baseline compiler, it may be
that we need to shuffle any stack results down, because incoming
arguments are consumed by the call.
Note that support for actually returning multiple values is not yet
implemented in this patch; we're just adding infra. Also note that Ion
support isn't there yet either. However all tests pass, because no
FuncType that has more than one result gets past the validator.
Differential Revision: https://phabricator.services.mozilla.com/D56756
--HG--
extra : moz-landing-system : lando
This changes the implementation of getLCovInfo to use CollectScriptCoverage.
This uses the filename/funname information that was captured when the script
was created. This is what the browser ccov tasks use and this change allows
our tests to better test that mode.
Differential Revision: https://phabricator.services.mozilla.com/D58668
--HG--
extra : moz-landing-system : lando
Deprecate collecting coverage info onto LCovRealm without IsLCovEnabled being
set. This patch adds annotations to tests that need it. A subsequent patch
will remove the mode this tests relied on and they will instead test the same
pathways we use for browser ccov tasks.
Differential Revision: https://phabricator.services.mozilla.com/D58667
--HG--
extra : moz-landing-system : lando
Also remove the test blacklist from jit_test.py and use 'skip-if' directives
in the relevant tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D58714
--HG--
extra : moz-landing-system : lando
This synchronizes some jit-test annotations to fix some warnings when running
the jit-tests.
Differential Revision: https://phabricator.services.mozilla.com/D58709
--HG--
extra : moz-landing-system : lando
At the end of any successful install, both the stub installer and full installer
(in interactive mode) attempt to launch the newly installed copy. But currently,
they first check if any copy of Firefox [1] is already running, and skip doing
that launch if so. The reason for this is that it used to be the case that no
two instances of Firefox could ever be running under default conditions because
there was only one default profile and it would be in use. It's clear that this
is the reason for the check because an exception is made for Developer Edition,
which had its own default profile and so wasn't subject to this restriction.
But now, we have per-install profiles by default, so there's no longer any need
to have this check, because launching the new instance won't be blocked by the
fact that there's already an instance running; all we're doing is creating
false positive prompts for something that isn't an issue anymore. So, this
patch removes the check and the prompt.
[1] At least that's the intent, but because of bug 1600905 we're actually now
checking for any Gecko-based product, because that's the best we can now do.
Differential Revision: https://phabricator.services.mozilla.com/D56959
--HG--
extra : moz-landing-system : lando
The function was moved during Bug 1582870 and
we lost the return statement somehow.
Differential Revision: https://phabricator.services.mozilla.com/D58798
--HG--
extra : moz-landing-system : lando
Since the name can be an undefined grip, there
could be case where the name would be an object
and not a React element, making the rendering fail.
This patch fixes that and adds a test to ensure
this does not regress.
Differential Revision: https://phabricator.services.mozilla.com/D58747
--HG--
extra : moz-landing-system : lando
By making the IStream object free-threaded (or "agile"), IStream::Read will be
called off the main thread. So we can wait until favicon is created.
Depends on D56478
Differential Revision: https://phabricator.services.mozilla.com/D56479
--HG--
extra : moz-landing-system : lando
Using JSON.stringify in dom/tests/mochitest/chrome/test_clonewrapper.xhtml might not be the best solution, because
the testObject contains ImageData objects.
Differential Revision: https://phabricator.services.mozilla.com/D58645
--HG--
extra : moz-landing-system : lando
Instead of using MOZ_CRASH/MOZ_ASSERT_UNREACHABLE for unreachable functions, we can
now use if-constexpr to avoid generating the unreachable calls in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D57324
--HG--
extra : moz-landing-system : lando
