This obviates dynamic checks in find about the state of the iterator, since
they're covered by the fact that we were able to obtain a FramePtr at all.
This does mean that we have to pass the pc separately. But that's symmetrical
with the insert method, so it's okay.
MozReview-Commit-ID: FgsDjHB2il4
--HG--
extra : rebase_source : cea62332ed0f138a41d4898c43945d1f981c6c98
Instead of using FrameIter::hasCachedSavedFrame, the code should instead try to
construct a FramePtr via LiveSavedFrameCache::getFramePtr, which returns a
Maybe<FramePtr>. If that is Some, then we know the frame at hand actually has a
flag, and we can test and set it.
Since the existing FrameIter::hasCachedSavedFrame screens out all wasm frames,
we change LiveSavedFrameCache::getFramePtr to do the same. However, the existing
behavior was incorrect, since wasm::DebugFrame does carry the flag; we'll fix
that in a later patch.
FrameIter::hasCachedSavedFrame asserted that jsJitFrame().isIonScripted(); this
is tested by isPhysicalIonFrame(), so that case is already covered.
MozReview-Commit-ID: 92wCc71s4nU
--HG--
extra : rebase_source : 54f60fbf298037448d9c051df3419df2a80f17d2
By design, the LiveSavedFrameCache holds the addresses of both live and dead
stack frames. This change wraps those addresses in an opaque type that can only
be compared for equality with other such values, and provides no interface to
retrieve the underlying pointer, ensuring statically that we will not
accidentally use a cache key to access memory.
MozReview-Commit-ID: 9Wom5gFVQls
--HG--
extra : rebase_source : e3dff595085973f1f10f57a67c192656c0bcd866
These threads should not have deep stacks, and as we can have a number
of them running simultaneously, it's beneficial to set the stack size to
something reasonably low.
A lot of our thread pools use the default stack size for the platform
they're on, which can be rather large (8MB, usually, on Linux and OS X)
and is probably too much for the typical thread in the thread pool
regardless. SharedThreadPool already has some logic for selecting a
reasonable stack size for worker threads; let's move that logic to
nsIThreadManager so that logic (and constant) can be shared more
broadly. (That we already have a couple of instances of
SharedThreadPool usage solely for this constant suggests that it is a
concept that should be available in a more central location.)
The code for serializing an EventKey in SerializeEventsArray does
something peculiar: it creates a temporary array of nsCStrings, copies
the appropriate strings from the event info for the key, and then
converts those into JavaScript strings. But we shouldn't need to do any
copying into the temporary array. We can do everything directly on the
strings from the event info themselves.
It seemed best to introduce a ToJSString for this purpose, which comes
in handy in a couple other places as well.
Once we've created the array of events for a given process, there's no
need to copy it in the array for all process events. We can Move() it
instead, which is more efficient.
When constructing DynamicEventInfo, we can require the extra keys to be
passed in by rvalue reference, rather than copying the entire array.
When registering dynamic events, we also don't need to construct an
entirely new nsCString to pass to the constructor; we can simply pass
the nsACString reference we received and go from there.
These methods are returning nsCString wrappers for static char arrays;
we only need to return nsDependentCStrings, rather than allocating and
copying entirely new nsCString objects.
mCompositorVsyncDispatcher is created and destroyed on main thread. But it is
accessed from Compositor thread or VSyncBridge thread. To avoid race condition
between main thread and Compositor thread/VSyncBridge thread,
mCompositorVsyncDispatcher needs to be protected by lock.
Automatic update from web-platform-tests
The syntax of the 'justify-items' property accepts a new 'legacy' value,
replacing the 'auto' value which is now parsed as invalid.
https://github.com/w3c/csswg-drafts/issues/1318
This change affects also to the 'place-items' shorthand, which doesn't
accept 'auto' and, for the time being, neither 'legacy'.
Link to the intent-to-ship-and-remove request:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/552753c1-9b2f-bb01-4fed-2ae621f2398e%40igalia.com?utm_medium=email&utm_source=footer
Bug: 726147, 726148
Change-Id: I219de66b813d350fe33f00a1d4369bed8e9a2350
Reviewed-on: https://chromium-review.googlesource.com/903162
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Darren Shen <shend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535593}
<!-- Reviewable:start -->
<!-- Reviewable:end -->
wpt-commits: 6d85a3b422cab97d032ad3db47cb741ca364185f
wpt-pr: 9400
reapplied-commits: 370e267e160568862f1fd9ec246ab5bb840f586e, fe4514c84e7ad28e46bad5da93381deb99b177f3, 7806af854343c043a2645a4034fdc7812f65daad, 9ddfd21554293dec5a4bf2e5375ae4f3c9f2ded0, 75f63c4d1ebc949647184fd60972fc7b9fd4affb, 1f3a5b496acd2288cc8cf0c32af86cb35157ea4e, 88b42bd5847abac58a62c4d6b33c1509bfce5f3d, 15c2e4c690700c6c115f8afe5e44ded10d943538, c8d461ef1437641ae7d4ea1d21e1e60cd62910b0, a6088a5f48ee299386a84d2f771902267d7355b1, 0634cd8f08ebe0905a9188fb1398c7b5f889c5dc, c8ee4a012dae506ae06bb5b2ad50942b04c1aaaa, c2c352456a4cf62dcc12f851138b04397675a445, b93a8879555d2fa7e7d4e00a275513a3a6338b35, b86e1331cb36634fd33677043b61fc0c1d8485bc, 44ddf14fd3346658c3223f13652073fafbfa48fa, a1a5840a6bb53e305ba02bcbeb215659342d0edb, 7465cb110ae5ec2e2ca73182caf5293f0efc8fd5, aad5349b3458bc3414e274b33fa86a1123901ff2, eca0907980d2769c449894a6277c60c1a306792f, 38626987c0cfd6e715cfcc6f4f1a1209191a03c5, e4a67f7ddcde6cd99348e9104bd7ed07074da44a, bb3c9990840a0fae2afc840b5952d7874785b112, 042d7adef0bdb9dc80e825c3997ace7519477c42, 99f1ea44fc7915b8b7b33bce4732fa8765fd3ac2, b81999f30c1516a70c153de51a0331d14c8faead
Automatic update from web-platform-tests
The test is currently flaky on the CQ (see associated bug) due to timing
out. This CL breaks down the test in a -small and a -large file. The
size of the largest test is also reduced from 500 cursors to 250
cursors. The two changes combined should greatly reduce the chance of
timeouts.
Bug: 708175
Change-Id: Ic58c59740a0176e6bc5e6e87b66c5d772a67526a
Reviewed-on: https://chromium-review.googlesource.com/908248
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535411}
<!-- Reviewable:start -->
<!-- Reviewable:end -->
wpt-commits: 13b72a6d7631a855aec02993c1ae170d096de8ea
wpt-pr: 9435
reapplied-commits: 370e267e160568862f1fd9ec246ab5bb840f586e, fe4514c84e7ad28e46bad5da93381deb99b177f3, 7806af854343c043a2645a4034fdc7812f65daad, 9ddfd21554293dec5a4bf2e5375ae4f3c9f2ded0, 75f63c4d1ebc949647184fd60972fc7b9fd4affb, 1f3a5b496acd2288cc8cf0c32af86cb35157ea4e, 88b42bd5847abac58a62c4d6b33c1509bfce5f3d, 15c2e4c690700c6c115f8afe5e44ded10d943538, c8d461ef1437641ae7d4ea1d21e1e60cd62910b0, a6088a5f48ee299386a84d2f771902267d7355b1, 0634cd8f08ebe0905a9188fb1398c7b5f889c5dc, c8ee4a012dae506ae06bb5b2ad50942b04c1aaaa, c2c352456a4cf62dcc12f851138b04397675a445, b93a8879555d2fa7e7d4e00a275513a3a6338b35, b86e1331cb36634fd33677043b61fc0c1d8485bc, 44ddf14fd3346658c3223f13652073fafbfa48fa, a1a5840a6bb53e305ba02bcbeb215659342d0edb, 7465cb110ae5ec2e2ca73182caf5293f0efc8fd5, aad5349b3458bc3414e274b33fa86a1123901ff2, eca0907980d2769c449894a6277c60c1a306792f, 38626987c0cfd6e715cfcc6f4f1a1209191a03c5, e4a67f7ddcde6cd99348e9104bd7ed07074da44a, bb3c9990840a0fae2afc840b5952d7874785b112, 042d7adef0bdb9dc80e825c3997ace7519477c42, 99f1ea44fc7915b8b7b33bce4732fa8765fd3ac2, b81999f30c1516a70c153de51a0331d14c8faead
Automatic update from web-platform-tests
Include a basic test for parsing of the color function defined in CSS Color 4. This is upstreamed from a test added by dino@apple.com in http://trac.webkit.org/changeset/208116/webkit.
<!-- Reviewable:start -->
<!-- Reviewable:end -->
wpt-commits: 3554b60bc35e5fc78eb4e8caa1ad38f4e6bf38ac
wpt-pr: 9402
reapplied-commits: 370e267e160568862f1fd9ec246ab5bb840f586e, fe4514c84e7ad28e46bad5da93381deb99b177f3, 7806af854343c043a2645a4034fdc7812f65daad, 9ddfd21554293dec5a4bf2e5375ae4f3c9f2ded0, 75f63c4d1ebc949647184fd60972fc7b9fd4affb, 1f3a5b496acd2288cc8cf0c32af86cb35157ea4e, 88b42bd5847abac58a62c4d6b33c1509bfce5f3d, 15c2e4c690700c6c115f8afe5e44ded10d943538, c8d461ef1437641ae7d4ea1d21e1e60cd62910b0, a6088a5f48ee299386a84d2f771902267d7355b1, 0634cd8f08ebe0905a9188fb1398c7b5f889c5dc, c8ee4a012dae506ae06bb5b2ad50942b04c1aaaa, c2c352456a4cf62dcc12f851138b04397675a445, b93a8879555d2fa7e7d4e00a275513a3a6338b35, b86e1331cb36634fd33677043b61fc0c1d8485bc, 44ddf14fd3346658c3223f13652073fafbfa48fa, a1a5840a6bb53e305ba02bcbeb215659342d0edb, 7465cb110ae5ec2e2ca73182caf5293f0efc8fd5, aad5349b3458bc3414e274b33fa86a1123901ff2, eca0907980d2769c449894a6277c60c1a306792f, 38626987c0cfd6e715cfcc6f4f1a1209191a03c5, e4a67f7ddcde6cd99348e9104bd7ed07074da44a, bb3c9990840a0fae2afc840b5952d7874785b112, 042d7adef0bdb9dc80e825c3997ace7519477c42, 99f1ea44fc7915b8b7b33bce4732fa8765fd3ac2, b81999f30c1516a70c153de51a0331d14c8faead
Automatic update from web-platform-tests
Also some more documentation.
Tried to make the various situations a bit clearer, with documentation
and code. And shared code for layout abortion.
The code used to call MaybeUpdateFragmentBfcOffset() quite
unconditionally based on an *end* offset inside the block. I found it
confusing to use an end offset as a BFC start offset. The code was
correct, though, since MaybeUpdateFragmentBfcOffset() wouldn't do
anything if the BFC offset was already known (which would be the case
if had children with actual size, for instance, making for a strange
BFC offset in that case). We'll now only call
MaybeUpdateFragmentBfcOffset() if BFC offset is unknown.
That's the only time end_bfc_block_offset can actually be used as a BFC
start offset.
Fixed one bug, though: A block with explicit height:0 ate the input
margin, rather than letting it collapse through and propagate to
subsequent layout input nodes. The intention of the code was just to get
rid of the last child margin, since height was non-auto. Now we check if
we have a BFC offset before doing so. If we have BFC offset, it means
that no input margins should collapse through. And if we DON'T have a
BFC offset, leave the margins alone for subsequent layout input nodes.
Otherwise we'd just lose them.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Iec8cea316015c6d36ef6bab9acbe826513222b1d
Reviewed-on: https://chromium-review.googlesource.com/907549
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535273}
<!-- Reviewable:start -->
<!-- Reviewable:end -->
wpt-commits: 19b995f0100dcc3c163153bd7e0a32249d736034
wpt-pr: 9430
reapplied-commits: 370e267e160568862f1fd9ec246ab5bb840f586e, fe4514c84e7ad28e46bad5da93381deb99b177f3, 7806af854343c043a2645a4034fdc7812f65daad, 9ddfd21554293dec5a4bf2e5375ae4f3c9f2ded0, 75f63c4d1ebc949647184fd60972fc7b9fd4affb, 1f3a5b496acd2288cc8cf0c32af86cb35157ea4e, 88b42bd5847abac58a62c4d6b33c1509bfce5f3d, 15c2e4c690700c6c115f8afe5e44ded10d943538, c8d461ef1437641ae7d4ea1d21e1e60cd62910b0, a6088a5f48ee299386a84d2f771902267d7355b1, 0634cd8f08ebe0905a9188fb1398c7b5f889c5dc, c8ee4a012dae506ae06bb5b2ad50942b04c1aaaa, c2c352456a4cf62dcc12f851138b04397675a445, b93a8879555d2fa7e7d4e00a275513a3a6338b35, b86e1331cb36634fd33677043b61fc0c1d8485bc, 44ddf14fd3346658c3223f13652073fafbfa48fa, a1a5840a6bb53e305ba02bcbeb215659342d0edb, 7465cb110ae5ec2e2ca73182caf5293f0efc8fd5, aad5349b3458bc3414e274b33fa86a1123901ff2, eca0907980d2769c449894a6277c60c1a306792f, 38626987c0cfd6e715cfcc6f4f1a1209191a03c5, e4a67f7ddcde6cd99348e9104bd7ed07074da44a, bb3c9990840a0fae2afc840b5952d7874785b112, 042d7adef0bdb9dc80e825c3997ace7519477c42, 99f1ea44fc7915b8b7b33bce4732fa8765fd3ac2, b81999f30c1516a70c153de51a0331d14c8faead
