Add support to WasmIonCompile for the instructions in the reftypes
proposal: ref.null, ref.is_null, table.get, table.set, table.grow,
table.size.
Also add support for the ref.eq instruction from the gc proposal.
Also update the test suite so that we will not ion-compile test cases
that use gc features that are not landed here.
Note that this patch does not change the compiler-selection behavior:
If --wasm-gc is enabled then only the baseline compiler will be used;
if --wasm-gc is not enabled then no compiler will recognize these
opcodes. Enabling Ion for reftypes content is the subject of
subsequent work.
Differential Revision: https://phabricator.services.mozilla.com/D20519
--HG--
extra : rebase_source : 807e3b6752b610effaa4d7f93f26035ffa29210e
extra : histedit_source : 197103a36157c78e8d36e6662422743532a4e0d2%2Cb4422d501e0ddfba6e830f69e381df6ea6da50da
This patch is changing a way to get ClearType paramters because registry key
may not be present. CreateMonitorRenderingParams() will return default values
if the corresponding registry key is not present.
--HG--
extra : source : 765a6f1fa3e7cbda3d841661fa3b4f71ad1b5ed1
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/layers/Layers.cpp:58:7 [-Wmissing-prototypes] no previous prototype for function 'FILEOrDefault'
gfx/layers/ipc/CompositorThread.cpp:26:25 [-Wmissing-prototypes] no previous prototype for function 'GetCompositorThreadHolder'
MINIMUM_TILE_COPY_AREA()
Differential Revision: https://phabricator.services.mozilla.com/D20266
--HG--
extra : rebase_source : 5c80a140cbd661644e2076a8852a0cfe58539083
extra : source : 7f44c2bcebce0b4bd549d653e4eff8b4bad71e29
And #include "BufferUnrotate.h" in BufferUnrotate.cpp for BufferUnrotate() function prototype.
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
gfx/2d/BufferUnrotate.cpp:17:6 [-Wmissing-prototypes] no previous prototype for function 'BufferUnrotate'
gfx/2d/DrawTargetCairo.cpp:195:6 [-Wmissing-prototypes] no previous prototype for function 'ReleaseData'
gfx/2d/DrawTargetCairo.cpp:201:18 [-Wmissing-prototypes] no previous prototype for function 'CopyToImageSurface'
gfx/2d/DrawTargetCairo.cpp:239:18 [-Wmissing-prototypes] no previous prototype for function 'GetAsImageSurface'
gfx/2d/DrawTargetCairo.cpp:251:18 [-Wmissing-prototypes] no previous prototype for function 'CreateSubImageForData'
gfx/2d/DrawTargetCairo.cpp:272:18 [-Wmissing-prototypes] no previous prototype for function 'ExtractSubImage'
gfx/2d/DrawTargetCairo.cpp:308:18 [-Wmissing-prototypes] no previous prototype for function 'GetCairoSurfaceForSourceSurface'
gfx/2d/DrawTargetRecording.cpp:26:6 [-Wmissing-prototypes] no previous prototype for function 'RecordingSourceSurfaceUserDataFunc'
gfx/2d/DrawTargetRecording.cpp:272:6 [-Wmissing-prototypes] no previous prototype for function 'RecordingFontUserDataDestroyFunc'
gfx/2d/DrawTargetWrapAndRecord.cpp:26:6 [-Wmissing-prototypes] no previous prototype for function 'WrapAndRecordSourceSurfaceUserDataFunc'
gfx/2d/DrawTargetWrapAndRecord.cpp:358:6 [-Wmissing-prototypes] no previous prototype for function 'WrapAndRecordFontUserDataDestroyFunc'
gfx/2d/FilterNodeSoftware.cpp:1816:6 [-Wmissing-prototypes] no previous prototype for function 'IsAllZero'
gfx/2d/FilterNodeSoftware.cpp:183:37 [-Wmissing-prototypes] no previous prototype for function 'CloneAligned'
gfx/2d/MacIOSurface.cpp:442:6 [-Wmissing-prototypes] no previous prototype for function 'MacIOSurfaceBufferDeallocator'
gfx/2d/QuartzSupport.mm:38:6 [-Wmissing-prototypes] no previous prototype for function 'cgdata_release_callback'
gfx/2d/ScaledFontMac.cpp:191:10 [-Wmissing-prototypes] no previous prototype for function 'CalcTableChecksum'
gfx/2d/ScaledFontMac.cpp:224:5 [-Wmissing-prototypes] no previous prototype for function 'maxPow2LessThan'
gfx/2d/unittest/TestCairo.cpp:12:6 [-Wmissing-prototypes] no previous prototype for function 'TryCircle'
Differential Revision: https://phabricator.services.mozilla.com/D20263
--HG--
extra : rebase_source : b42bce33ed899caeb89e462d99a5cde29a9bb559
extra : intermediate-source : 7923cc86a6394bcd2fb3b7e38f458a5180d31e11
extra : source : 02388f2454e8842d2c023bf9f9fab222d8130093
MacroAssembler::wasmReserveStackChecked takes a parameter |amount|, which
appears to be the number of bytes pushed by the prologue, not including for
the wasm::Frame, up to this point. If this value is zero, the stack overflow
check is omitted.
I believe this logic is incorrect and that the stack overflow check should
never be omitted. There's no way any non-leaf call could really use zero
bytes of stack in total, since there would be no place to store the return
address.
I believe this code worked by accident, for the following reason: |amount| is
never zero. That happens because, currently, wasm::Frame is 3 words (except
on ARM64). That's 12 bytes or 24 bytes, depending on word size. At some
point I imagine that |amount| is rounded upwards, prior to the call to
MacroAssembler::wasmReserveStackChecked, so that |amount| +
sizeof(wasm::Frame) is 0 % 16.
If amount was originally zero, then it will be adjusted upwards to 4 (16-12)
on a 32-bit system and to 8 (32-24) on a 64-bit system. The end effect is
that |amount| can never be zero here.
The fix is simply to remove the early exit.
Setting the permission has to happen after the call to parseManifest so
it may be set if the manifest is already cached. Also grant permission
when installed from permanent private browsing.
Differential Revision: https://phabricator.services.mozilla.com/D18879
--HG--
extra : moz-landing-system : lando
The AutoDebuggerJobQueueInterruption destructor asserts that the Debugger has
properly managed its hooks' asynchronous jobs. But this assertion clearly only
applies when the AutoDebuggerJobQueueInterruption is properly initialized;
otherwise, the debuggee's job queue is still in place.
Unfortunately, the destructor was using the wrong test to determine whether the
debuggee's queue had been saved. This patch makes it uses the `initialized`
method, rather that checking the `cx` field, which is always initialized.
Differential Revision: https://phabricator.services.mozilla.com/D20575
--HG--
extra : moz-landing-system : lando
This code was already handling the world going away, but did not handle the case
of just getting unbound, which can happen if some selection listener (e.g.,
AccessibleCaret) flushes layout.
Differential Revision: https://phabricator.services.mozilla.com/D20469
--HG--
extra : moz-landing-system : lando
This will avoid trying to generate them during artifact builds.
Depends on D20587
Differential Revision: https://phabricator.services.mozilla.com/D20436
--HG--
extra : moz-landing-system : lando
ZoneCellIter can return cells that are about to be finalised in the next GC
slice. These cells can be used briefly but cannot be kept around and the GC
needs this behaviour.
This change introduces ZoneCellIterSafe which will not return about-to-be
finalised cells. Zone::cellIter() will use it now, the old behaviour is now
in cellIterUnsafe().
Update several uses of cellIter() to cellIterUnsafe() where that behaviour
is needed.
Differential Revision: https://phabricator.services.mozilla.com/D19890
--HG--
extra : moz-landing-system : lando
* Be sure to set mInitResult = S_OK when we've already done process-wide initialization;
* Don't bother checking for Win32 lockdown unless we're not in the parent process
Differential Revision: https://phabricator.services.mozilla.com/D20386
--HG--
extra : moz-landing-system : lando
By stopping composite during handling device reset, we could reduce a possibility of crashes.
Differential Revision: https://phabricator.services.mozilla.com/D20440
--HG--
extra : moz-landing-system : lando
Depends on D20195
This series of patches depends on the patch from [Bug 1525238](https://bugzilla.mozilla.org/show_bug.cgi?id=1525238)
- adds method to identify a CSS Rule actor by id
- adds context menu option to the Changes panel to allow copying the rule's authored text to the clipboard
Differential Revision: https://phabricator.services.mozilla.com/D20196
--HG--
extra : moz-landing-system : lando
This series of patches depends on the patch from [Bug 1525238](https://bugzilla.mozilla.org/show_bug.cgi?id=1525238)
This patch adds a new method to the StyleRuleActor on the server to expose the full text content of a CSS rule over the protocol to the client. This means exposing the CSS rule's authored text including comments and any nested rules if the target rule is an ancestor rule, like @media or @supports.
There's minor refactoring to include additional rule types for which StyleRuleActors will be created: @supports, @media, @keyframes. These are not explicitly rendered in the Rule view and shouldn't impact it. The Rule view filters for CSS Style Rules, element inline style and has special handling for keyframe at-rules.
Differential Revision: https://phabricator.services.mozilla.com/D20195
--HG--
extra : moz-landing-system : lando
FramePointerStackWalk can trip ASAN when walking the stack and reading outside
of ASAN-protected objects.
Differential Revision: https://phabricator.services.mozilla.com/D20208
--HG--
extra : moz-landing-system : lando
This bug occurs under the following conditions:
- The clip chain instance has multiple clip items.
- The first item in the clip chain is a clip rectangle, with:
- ClipMode::Clip
- Is in the same coordinate system as the primitive.
In this case, the code would skip adding the clip rect to the
mask (due to the same coord system). However, the logic that
determines whether to render subsequent masks with blend disabled
or multiplicative blend was only considering the index of the
clip item in the clip chain. In this case, these masks would
get added to the blend enabled batches, but the first clip mask
which would have written the initial mask values was skipped.
The end result was that the subsequent clip masks would be
blending with uninitialized render target contents from a previous
frame.
This patch changes the logic to track when the first clip mask
has actually been added to the batch, rather than relying on
the index. In this case, it means that the rounded rect mask
will get drawn in the blend disabled path, writing the correct
mask values without blending with the existing render target contents.
Differential Revision: https://phabricator.services.mozilla.com/D20590
--HG--
extra : moz-landing-system : lando
Without this patch, if we got a display item with the root clip id, we
would always clip that display item with the root clip of the enclosing
pipeline. However, this violates the documented semantics on
ClipId::root() which states that it effectively does no clipping.
Specifically, it could end up doing clipping if the display item was
part of a scrollframe that was scrolled such that the display item
extended beyond the enclosing pipeline.
This patch adds an extra argument to some of the flattening functions -
the flag is true when recursing the DL between a pipeline item and the
first stacking context that has a clip. For these items, the pipeline
clip is applied. Once inside the stacking context, the pipeline clip is
not applied.
Differential Revision: https://phabricator.services.mozilla.com/D20483
--HG--
extra : moz-landing-system : lando
The old complicated code here was working around a fundamental race in the
test. The test was trying to do the following:
1) Open a new tab. This sends an IPC message to do that and to start loading
about:blank in the tab.
2) Add a "load" listener. This sends an IPC message to add the listener.
3) Start loading the URL we really want to load. This sends an IPC message to
start the load.
There are two races here: the message from step 2 can be received before or
after the about:blank load is done, and the message from step 3 can be received
before or after the about:blank load is done. If step 2 wins the race (we add
the listener before the about:blank load is done) but step 3 loses the race
(new load starts only after the about:blank load is done), then we would get a
load event for the about:blank, not for the url we care about.
The test worked around this by having step 2 add a listener for the
"DOMDocElementInserted" event, which about:blank did not fire. Then when that
happened (indicating that the load from step 3 is now in progress), it added a
"load" listener. This fixed the race.
Bug 1528146 fixed about:blank to also fire "DOMDocElementInserted", so the test
became racy again. Now if the "DOMDocElementInserted" listener got added
_after_ the about:blank load had fired that event (which is what usually
happened), then the test passed. But if the IPC message from step 2 to add the
"DOMDocElementInserted" listener won the race against the about:blank load
firing "DOMDocElementInserted", then we added the "load" listener too early and
got the "load" event for the about:blank, not the document we cared about.
The fix is to just use the (now) existing openNewForegroundTab function which
lets us pass in a url, then wait until that URL is loaded, instead of trying to
reinvent that wheel.
There is an additional ride-along change to make openNewForegroundTab always
create a new process in this test, which is the original intent of the test but
wasn't necessarily guaranteed by the old code.
Differential Revision: https://phabricator.services.mozilla.com/D20544
--HG--
extra : moz-landing-system : lando
Will ask for r? from janerik once product has approved the data collected here.
Differential Revision: https://phabricator.services.mozilla.com/D19529
--HG--
extra : moz-landing-system : lando