These "shadow scheduler" tasks will generate artifacts per-push on autoland.
Basically, given the scheduling algorithms defined in
TASKGRAPH_OPTIMIZE_STRATEGIES, which tasks *would* have been scheduled on this
push.
This will allow us to download the artifacts and run comparisons against the
baseline to see whether things like code coverage or machine learning are
making the situation better or worse.
Differential Revision: https://phabricator.services.mozilla.com/D40427
--HG--
extra : moz-landing-system : lando
This will allow us to easily tweak these values from the optimization strategy.
Differential Revision: https://phabricator.services.mozilla.com/D40206
--HG--
extra : moz-landing-system : lando
This allows test tasks to declare a static optimization name, which can then be
swapped in and out from the optimize code without needing to update the
transforms. This will make it easier to change optimization strategies or run
experimental ones.
Differential Revision: https://phabricator.services.mozilla.com/D40204
--HG--
extra : moz-landing-system : lando
This should make this fail cleanly on OOM rather than crashing, which should make this crash go away (without reducing memory usage obviously). The problem was the lack of hasHash/ensureHash methods that we use to handle OOM when generating unique IDs for GC things. I also tidied the equivalent code for ObjectGroupRealm::NewEntry (FallibleHashMethods is already implemented for MovableCellHasher).
We could further improve this by giving each script an immutable hash code on creation if you think it's worth the tradeoff of storing this for every script.
Differential Revision: https://phabricator.services.mozilla.com/D41233
--HG--
extra : moz-landing-system : lando
This adds some polish to the existing markup, making it all a bit more intuitive.
1. Associate the graph legend to the fake table so it becomes kind of the caption for that table for screen reader users. Screen reader users will then hear something like "Table showing a graph of .." plus the table information they already get since bug 1573197 landed.
2. Actually combine the number and tab's title into a spoken label for screen readers on each radio button, and for the description, use the explanatory paragraph's content. That way, screen reader users can just tab and arrow to each item in focus mode and hear all the relevant information at once without having to skip back and forth between the elements.
Differential Revision: https://phabricator.services.mozilla.com/D42082
--HG--
extra : moz-landing-system : lando
We do have test coverage for this
(layout/style/test/test_visited_reftests.html), but it seems that that uses
snapshotWindow() / drawWindow() and that may not use the WR code paths? It seems
we may be missing a bit of test coverage there. Is this expected?
Differential Revision: https://phabricator.services.mozilla.com/D41935
--HG--
extra : moz-landing-system : lando
This patch adds `RunOnShutdown`, which allows the caller to supply any callable
to be invoked during the specified shutdown phase. This allows us to do more
than just clear smart pointers without needing to write a bunch of observer
service boilerplate.
We use `std::function` to hold the callable.
Differential Revision: https://phabricator.services.mozilla.com/D41816
--HG--
extra : moz-landing-system : lando
This patch adds some subtests that exercise the new
`text-decoration-thickness` subproperty. It also adjusts the
expected serialization for some existing subtests (`currentcolor`
and `solid`) which are simply setting a subproperty to its
initial value, and therefore should serialize to the shorthand's
own effective initial value, which is "none".
Differential Revision: https://phabricator.services.mozilla.com/D42058
--HG--
extra : moz-landing-system : lando
ComputedStyle* aComputedStyle doesn't provide any extra value over just aStyle.
Lots of these should be const and what not, oh well.
Differential Revision: https://phabricator.services.mozilla.com/D41933
--HG--
extra : moz-landing-system : lando
(This basically addresses the review comments that I missed in
bug 1105868 part 4. My bad.)
Differential Revision: https://phabricator.services.mozilla.com/D42134
--HG--
extra : moz-landing-system : lando
Some worker debugger runnables (the ones that want to evaluate script against a
debugger sandbox) depend on the JSContext being in a particular Realm before
they run, but don't really store which Realm that should be. Instead of
propagating that state via the current Realm of the JSContext across nested
event loops, we want to propagate it explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D41790
--HG--
extra : moz-landing-system : lando
WasmInstance::funcRef has 'FailureMode::FailOnInvalidRef' so it looks like we
just need to report the OOM and return InvalidRef.
Differential Revision: https://phabricator.services.mozilla.com/D42050
--HG--
extra : moz-landing-system : lando
