Turns out that metrics_index.py is not only valid Python but is also valid
mozbuild format. So long as our constants are lowercase (uppercase is reserved)
we can `include()` the index and read the arrays of files to tell
`GeneratedFile` every file it depends on, not just the index.
We do have to transform the paths, though, as I still maintain that paths
relative to TOPSRCDIR makes more sense for the index, but the `inputs` to
`GeneratedFile` are relative to the dir of the `moz.build`.
Differential Revision: https://phabricator.services.mozilla.com/D91961
Without that, we are closing the toolbox by destroying its tab or window.
This prevent correctly waiting for toolbox full destruction and was causing leaks
in debug builds on browser_webconsole_trackingprotection_errors.js and browser_aboutdebugging_devtools.js.
Differential Revision: https://phabricator.services.mozilla.com/D91917
With bug 1620280's patches, browser_dbg-windowless-workers-early-breakpoint.js started failing
because of a removed breakpoint being re-added after being removed!
This relates to the usage of `PROMISE` in the action object,
which triggers the promise middleware, itself making the action being emitted twice.
One time immediately, and another time after the promise is resolved.
So that the reducer was adding the breakpoint twice.
Differential Revision: https://phabricator.services.mozilla.com/D91720
This was relevant before as we were calling "ThreadActor.getSources"/"StyleSheets.getStyleSheets",
and by the time these requests resolved, we would have navigated to a new URL and need to ignore their response.
I think it is safe to drop this now as these requests may still be pending if we use legacy listeners,
but the call to unwatchResources should immediately unregister _onResourceAvailable and ignore any pending data
coming late.
Differential Revision: https://phabricator.services.mozilla.com/D90428
Using WrapAndRecord for printing was just a way to minimize risk when
working on the RecordingDrawTarget. We would prefer to eliminate
WrapAndRecord.
These leaves some of old function names around just to keep the patch
small. If it sticks we can fix those names.
Differential Revision: https://phabricator.services.mozilla.com/D91988
This has no functional change beyond our telemetry reporting. It inverts
our feature configuration such that we get an explicit reason why we
don't turn on some features, instead of just "disabled by default."
Differential Revision: https://phabricator.services.mozilla.com/D91980
This uses the Pivot class to search backwards and forwards from the current offsets until either end is reached, or an accessible that is either a line break or has a block frame, is found, and therefore constitutes a boundary of interest.
Differential Revision: https://phabricator.services.mozilla.com/D91407
So that:
* It accounts for @page.
* It is correctly serialized and deserialized over IPC.
* It's nicer to use.
Depends on D92004
Differential Revision: https://phabricator.services.mozilla.com/D92005
We generate builtin call for MTruncateToInt32 operation for floating points types,
so we need to add a tls dependency.
I inserted NYI for arm64 because Ion doesn't support arm64.
Differential Revision: https://phabricator.services.mozilla.com/D89550
We generate builtin call for Mod operation for Double types, so we need
to add a tls dependency. In this patch I've added it.
Differential Revision: https://phabricator.services.mozilla.com/D89243
In this patch we add a tls dependency for the remaining nodes which use
BuiltinThunk to call c++ runtime. By ABI requirements WasmTlsReg should
be set.
Differential Revision: https://phabricator.services.mozilla.com/D89239
To be able to call c++ runtime via Builtin thunk we need to set up WasmTlsReg.
In this patch I create dependencies from MIR level to Codegen to be sure that WasmTlsReg is alive
when we call runtime in div/mod i64 for arm.
Differential Revision: https://phabricator.services.mozilla.com/D88762
x86 has few register so to do div/mod for i64 it call the runtime
and clobber almost all gp registers including WasmTlsReg.
To be able to call c++ runtime via Builtin thunk we need to set up WasmTlsReg.
In this patch I create dependencies from MIR level to Codegen to be sure that WasmTlsReg is alive
when we call runtime.
Differential Revision: https://phabricator.services.mozilla.com/D88524
We have a tls dependency in callWithABI for wasm because we call builtins via BuiltinThunk.
Last one requires that tls to be loaded. In this patch I gradually extend callWithABI interface to
pass offset to tls. This allows us to preserve tls and load it by offset in callWithABI and frees us from
the Frame::tls dependency.
Differential Revision: https://phabricator.services.mozilla.com/D88426
Let's see following code and let's assume that wasm-compiler is ion:
call foo
call bar
Ion can clobber tls inside foo and then it can go with clobbered tls into bar.
There will be a crash if bar uses tls. At compile-time we don't know whether bar will use tls or not.
It works when we restore tls each time when we are returning from a function because of the current frame structure.
But now, when we want to get rid of Frame::tls we should guarantee that Ion doesn't clobber tls inside a function.
In fact we forces Ion to restore tls iff it clobbers it and it is a rare case.
Baseline doesn't need such logic because of its private stack slot for tls.
Differential Revision: https://phabricator.services.mozilla.com/D83061