This commit changes the throw stub to clobber most registers
before jumping to the catch landing pad. The exact details of
which registers to clobber is commented in the stub.
Differential Revision: https://phabricator.services.mozilla.com/D134630
This commit did a fresh pull of all our vendored
spec-test repositories. I updated all repositories instead
of just the exception-handling one so that diffs between
base and dependent proposals remained minimized.
Differential Revision: https://phabricator.services.mozilla.com/D134631
CLOSED TREE
Backed out changeset 579f107e3a5e (bug 1748458)
Backed out changeset 89ac7dfe4265 (bug 1748458)
Backed out changeset 95c08b064dea (bug 1748478)
This function computes squares of values, but the results are the same magnitude than the source components.
In fact, they can't be larger than the biggest component. Therefore, by doubling the precision of computation we can guarantee that the result will be finite if the source data is finite.
An alternative approach would be to figure out a different computation path that would preserve the precision as it goes. Looks to not be necessary here.
Differential Revision: https://phabricator.services.mozilla.com/D135140
Rather than defining a distinct `Parameter` class for Gecko, this now uses the
`extend_parameters_schema` utility function (which mobile repos are already
using).
As a consequence, shared parameters are now defined in standalone taskgraph.
And only Gecko-specific parameters are listed in
`gecko_taskgraph/parameters.py`
The only exception is `project` which gets redefined so we can override the
standalone taskgraph default (since it derives `project` from the repo name,
which doesn't work for Gecko).
Differential Revision: https://phabricator.services.mozilla.com/D134515
Due to a typo in a preprocessor condition, the RenderCompositorOGLSWGL
destructor was not destroying its EGL surface on Android. This meant
that subsequent RenderCompositorOGLSWGL instances were unable to
initialize, as the underlying window surface was still in use. After
attempting to reinitialize the compositor in response to an error, this
resulted in an endless loop of trying and failing to initialize.
After fixing this typo, RenderCompositorOGLSWGL correctly cleans up
after itself and subsequent instances are able to initialize.
Differential Revision: https://phabricator.services.mozilla.com/D135117
Many revisions later... this is my best shoehorning attempt of webrtc's trace
events into the profiler.
It is not an optimal fit as the profiler wants a static schema, and the trace
event framework provides labels and values for the args dynamically.
But it allows displaying all args in the profiler which is a big step for
low-maintenance webrtc trace event integration into the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D135031
This patch adds a part of TraceEvent.h that we had previously skipped. It
handles the conversion from the arg-ful TRACE_EVENTn forms to the internal
representation which carries around a dynamic number of args (num_args and
friends).
This allows us to hook into GeckoTraceEvent.h at a higher level, where all trace
events end up, with or without args.
Differential Revision: https://phabricator.services.mozilla.com/D135029
I'm gonna guess there was no existing use of the tuple
serialization/deserialization code, because `Bytes` doesn't exist in the
deserializer, and cannot possibly function properly on tuple members that
serialize to a non-constant size, since it's called on a default-constructed
tuple.
This patch took inspiration in the deserializer for Variant and seems to work
fine.
Differential Revision: https://phabricator.services.mozilla.com/D135028
The Runnable markers in the profilers are handy, but miss many types of
runnables. This includes most of those that wrap another runnable and run that
at a (possibly) later time.
AbstractThread, TaskDispatcher and TaskQueue does this for e.g. tail dispatched
tasks.
TaskQueueWrapper does this when wrapping webrtc tasks (and Mozilla Runnables) to
be run in a Mozilla TaskQueue with some overhead on the stack.
DelayedRunnable wraps a runnable to be run after a timeout.
It would perhaps be better in many cases to ignore the intermediate runnables,
but I haven't seen a straight forward way to achieve this.
More detailed data could be added on a case by case basis, for instance the
delay for a DelayedRunnable (incl. actual vs. target delay) or the scope of a
task in which a tail-dispatched runnable was dispatched. But this is also true
for the status quo (for instance the time from dispatch to run) so I leave these
ideas as future work.
Differential Revision: https://phabricator.services.mozilla.com/D135027
This allows to test and enable the different portals separately. Make
the print portal work only when actually running under flatpak by
default, given it needs more work as per the regressing bug.
And while at it fix a minor leak and some typos in that code.
Differential Revision: https://phabricator.services.mozilla.com/D135120
What is happening here is that the left hand side operand of the equality
operator is an integer, and the right hand side operand is a float, that has a
fractional value that is not null. The left hand side gets promoted to a float
and the equality check fails.
In practice, the graph is always instantiated with a sample-rate that is an
integer, and this conversion happens without explicit rounding, so it's a floor
operation. However, the sample-rate of an AudioContext is a float, so there is
an edge case where the graph and the AudioContext don't have the same
sample-rate.
I don't think this matters in practice.
Switching to comparing that the graph passed as a parameter is the same as the
graph the AudioNode is in is enough to assert here and doesn't suffer from the
sample-rate problem.
Differential Revision: https://phabricator.services.mozilla.com/D135044