Summary:
the periodic file updates keep adding new reviews, and it's easy to fall behind.
This adjusts the script so it clears out any previous submissions that are still awaiting review.
Reviewers: jlorenzo
Reviewed By: jlorenzo
Bug #: 1452159
Differential Revision: https://phabricator.services.mozilla.com/D872
--HG--
extra : rebase_source : 4a36ddd91bf7e971fd6b424d02117bd4739a91ed
We'd really like the LiveSavedFrameCache to be able to assert that, if a frame
has its hasCachedSavedFrame bit set, there is indeed a cache entry for it (if
the cache hasn't been cleared completely for a compartment mismatch). See the
explanation of LiveSavedFrameCache in Stack.h, and the comments in
LiveSavedFrameCache::find.
Sometimes we do find a cache entry for the frame, but execution in that frame
has progressed to a different source position since we cached it, so the
SavedFrame in that cache entry isn't useful. When this occurs, we used to simply
pop the cache entry, and report a miss: although this did create a situation
where a frame with its bit set had no cache entry, that was only temporary: we
would push a new entry for the frame as we build the new SavedFrame chain.
Unless, of course, SavedFrame construction encounters an OOM and the whole
process aborts early.
This patch clears a frame's hasCachedSavedFrame bit when we report a cache miss
due to a pc mismatch. Under normal circumstances, the frame will soon be cached
again and its bit re-set. If an OOM does occur, the absence of the cache entry
is accurately reported.
--HG--
extra : rebase_source : 5e980e5732b7fd5ff1dd6a68c1a49a1c538010c6
extra : source : 2ed6d9d910b0f3dd24e163f17e3a70d327286582
This entails implementing corresponding methods on each variant of
FramePtr::Ptr.
--HG--
extra : rebase_source : 3b810cd4d3aa78d014f830acbf2d6e6794694415
extra : source : 014fdec944a9e82fd74e7ff4644cb4f9e96076c2
OOM tests often depend on invoking a function repeatedly, failing a different
allocation each time. Flushing the caches helps ensure consistent behavior from
one invocation to the next.
--HG--
extra : rebase_source : 0bf4a46c7c3e0bceb0fe77bbf96e422558a988c4
extra : source : 1a11067ab1e6b62602b79081e3208dcad31807bd
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : f0784c0c5b2e39d2078a5aff72be03b52e413139
extra : intermediate-source : 635153e1dcdc442f8d72727b6fe504842b4ffa31
extra : source : bf011140459cc227c9435e3960770bafb3cecb8e
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
Both Blink and WebKit pass the added tests. But of course all this stuff was
untested initially, and my initial naive implementation would fail them.
MozReview-Commit-ID: KayYNfTXb5h
Kinda tricky because :host only matches rules on the shadow root where the rules
come from. So we need to be careful during invalidation and style sharing.
I didn't use the non_ts_pseudo_class_list bits because as soon as we implement
the :host(..) bits we're going to need to special-case it anyway.
The general schema is the following:
* Rightmost featureless :host selectors are handled inserting them in the
host_rules hashmap. Note that we only insert featureless stuff there. We
could insert all of them and just filter during matching, but that's slightly
annoying.
* The other selectors, like non-featureless :host or what not, are added to the
normal cascade data. This is harmless, since the shadow host rules are never
matched against the host, so we know they'll just never match, and avoids
adding more special-cases.
* Featureless :host selectors to the left of a combinator are handled during
matching, in the special-case of next_element_for_combinator in selectors.
This prevents this from being more invasive, and keeps the usual fast path
slim, but it's a bit hard to match the spec and the implementation.
We could keep a copy of the SelectorIter instead in the matching context to
make the handling of featureless-ness explicit in match_non_ts_pseudo_class,
but we'd still need the special-case anyway, so I'm not fond of it.
* We take advantage of one thing that makes this sound. As you may have
noticed, if you had `root` element which is a ShadowRoot, and you matched
something like `div:host` against it, using a MatchingContext with
current_host == root, we'd incorrectly report a match. But this is impossible
due to the following constraints:
* Shadow root rules aren't matched against the host during styling (except
these featureless selectors).
* DOM APIs' current_host needs to be the _containing_ host, not the element
itself if you're a Shadow host.
Bug: 992245
Reviewed-by: xidorn
MozReview-Commit-ID: KayYNfTXb5h
Source-Repo: https://github.com/servo/servo
Source-Revision: cb754b262747e7cab794411df55588f0f0b30b5e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2ebbb2578ff9dbadfe905ae501cd52bd61a9fe9a