Entry storage allocation now occurs on the first lookupForAdd()/put()/putNew().
This removes the need for init() and initialized(), and matches how
PLDHashTable/nsTHashtable work. It also removes the need for init() functions
in a lot of types that are built on top of mozilla::Hash{Map,Set}.
Pros:
- No need for init() calls and subsequent checks.
- No memory allocated for empty tables, which are not that uncommon.
Cons:
- An extra branch in lookup() and lookupForAdd(), but not in put()/putNew(),
because the existing checkOverloaded() can handle it.
Specifics:
- Construction now can take a length parameter.
- init() is removed. Explicit length-setting, when necessary, now occurs in the
constructors.
- initialized() is removed.
- capacity() now returns zero when the entry storage is absent.
- lookupForAdd() is no longer `const`, because it can instantiate the storage,
which requires modifications.
- lookupForAdd() can now return an invalid AddPtr in two cases:
- old: hashing failure (due to OOM in the hasher)
- new: OOM while instantiating entry storage
The existing failure handling paths for the old case work for the new case.
- clear(), finish(), and clearAndShrink() are replaced by clear(), compact(),
and reserve(). The old compactIfUnderloaded() is also removed.
- Capacity computation code is now in its own functions, bestCapacity() and
hashShift(). setTableSizeLog2() is removed.
- uint32_t is used throughout for capacities, instead of size_t, for
consistency with other similar values.
- changeTableSize() now takes a capacity instead of a deltaLog2, and it can now
handle !mTable.
Measurements:
- Total source code size is reduced by over 900 lines. Also, lots of existing
lines got shorter (i.e. two checks were reduced to one).
- Executable size barely changed, down by 2 KiB on Linux64. The extra branches
are compensated for by the lack of init() calls.
- Speed changed negligibly. The instruction count for Bench_Cpp_MozHash
increased from 2.84 billion to 2.89 billion but any execution time change was
well below noise.
SplitStyleAbovePoint calls SplitNodeDeepWithTransaction repeatedly. If
SplitNodeDeepWithTransaction creates orphan node like this test case,
this crash occurs. So we should check whether node becomes orphan node.
Differential Revision: https://phabricator.services.mozilla.com/D1993
--HG--
extra : moz-landing-system : lando
What's going on is that nested XBL insertion points are completely unsound, and
we leave all sorts of kids in mInsertedChildren when bindings dynamically
change.
So if bindings change in a particular way so that the innermost insertion point
is cleared, but the outermost bindings aren't, like this, we end up with an
inconsistent flattened tree.
This prevents the inconsistent flattened tree in this case, though what ought
to happen in the SetXBLInsertionPoint(nullptr) case is setting the insertion
point to the outer insertion point.
But we don't keep track of all our insertion points, and I don't think it's
worth to fix that given XBL is going away unless it gives us more problems. See
also bug 1425362 & co.
Differential Revision: https://phabricator.services.mozilla.com/D3163
--HG--
extra : moz-landing-system : lando
GCHashMap will shortly lose its initialized() function, so we need another way
to indicate whether this table has been created. This patch changes it to use a
pointer instead.
--HG--
extra : rebase_source : 05ce9f2938d1fc8373cbac77c0b3bd62633f93d8
The accessibility tests currently rely, in many places, on lexical variables
defined in global frame scripts being available to other non-global frame
scripts. While that is currently the case, it will stop being so soon.
And, while the simplest solution would be to define them as properties on the
frame message manager by using `var` rather than `let`, storing references to
the current content window in a frame script scope is unsafe at best, and
should be avoided at all costs.
MozReview-Commit-ID: 4FCGtLgcFzl
--HG--
extra : rebase_source : d21206c9f119ca0ce61f9956f84a2e2d11484bca
Automatic update from web-platform-testsMerge pull request #10926 from Tavmjong/markers-orient
Add test for marker 'orient' attribute.
--
wpt-commits: eea0b54014e970a2f94f1c35ec6e18ece76beb76
wpt-pr: 10926
Automatic update from web-platform-testsMerge pull request #10275 from dstorey/svgaelement-additions
Add tests for rel, rellist, download, and text on SVGAElement
--
wpt-commits: 60f5bae752dd625ae83a730c635254cdb9f3d970
wpt-pr: 10275
Automatic update from web-platform-testsMerge pull request #10249 from dstorey/svg-document-element-events
Add test for DocumentAndElementEventHandlers in SVG
--
wpt-commits: 1529e32ac8073c48e872e7d705a10daa24decbbf
wpt-pr: 10249
Automatic update from web-platform-testsUse a .worker.js test for WorkerGlobalScope_requestAnimationFrame.
--
wpt-commits: 5a3a984492dcd1b1586576790922baf0a208dfb5
wpt-pr: 12293
Automatic update from web-platform-tests[LayoutNG] Pass constraint space to inline children for min/max.
Orthogonal flow root children are going to need to calculate an
extrinsic constraint space. We already got this right for direct block
children, but not for floated children of inline child nodes.
Three tests start to pass, but I wrote a new test as well, that's more
to the point (it used to fail a DCHECK, and then render incorrectly, if
we bypassed that).
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Iffea4e8cb26f41f8b5caac4bbb7185df5f62f7d7
Reviewed-on: https://chromium-review.googlesource.com/1162175
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581188}
--
wpt-commits: 25475a3887220baee22dfef032474040401d84e3
wpt-pr: 12297
Automatic update from web-platform-tests[css-grid] Change how percentage row tracks and gaps are resolved
The CSSWG decided to change how percentage row tracks and gutters
in a grid container with indefinite height are resolved.
The CSSWG issues are:
* https://github.com/w3c/csswg-drafts/issues/1921
* https://github.com/w3c/csswg-drafts/issues/509
So far they were resolved as "auto", like it happens with
percentage heights in regular blocks. But now they're going to behave
similar to what happens in the columns axis, they would be ignored
to compute the intrinsic height.
This causes that we need to repeat the track sizing algorithm
when we have a grid container with indefinite height
that has some percentage rows using the intrinsic height
calculated on the first pass. Then the percentages will be resolved
against the intrinsic height.
We are adding two new tests for this new behavior
on top of updating several tests that were using percentages.
We also add a test for content alignment and the second pass
when the row size changes, the last case fails due to crbug.com/871230.
JFTR, intent to implement and ship thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/CJgcT4hR7Rk/58WfZNbWBQAJ
BUG=846187
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-001.html
TEST=css/css-grid/grid-definition/grid-percentage-rows-indefinite-height-002.html
TEST=css/css-grid/alignment/grid-content-alignment-second-pass-002.html
Change-Id: I2a1959af6c95e0c47d294580599fdbf9bc432348
Reviewed-on: https://chromium-review.googlesource.com/1142409
Commit-Queue: Manuel Rego <rego@igalia.com>
Reviewed-by: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#581185}
--
wpt-commits: 244c6baf38953eac29840e2fbcb8a42dd8bafe88
wpt-pr: 12089
Daisuke Akatsuka
Martin Thomson
Nicholas Nethercote
Makoto Kato
Xidorn Quan
Cameron McCormack
Emilio Cobos Álvarez
Brindusan Cristian
makmm
Narcis Beleuzu
Francesco Lodolo (:flod)
Cosmin Sabou
Kris Maglione
Ciure Andrei
Dorel Luca
moz-wptsync-bot
Ms2ger
Chris Lilley
Morten Stenshorne
Luke Bjerring
Manuel Rego Casasnovas
Jean-Yves Avenard
Dale Harvey
Brian Hackett
Jan de Mooij
ExE Boss
Ed Lee
Andreea Pavel