After replacing precise line information from .debug_line with coarse
line information from DW_AT_call_{file,line}, it's very likely that
adjacent line records actually refer to identical file and line
numbers. Such adjacent records are not really useful and take up more
space than they should in the symbol file. We might as well merge them
and save ourselves some space.
Differential Revision: https://phabricator.services.mozilla.com/D25473
--HG--
extra : moz-landing-system : lando
DW_TAG_subprogram DIEs sometimes have child DW_TAG_lexical_block DIEs
which in turn contain child DW_TAG_inlined_subroutine DIEs that we woud
like to look at. If we skip the DW_TAG_inlined_subroutine DIEs, we miss
important information. We therefore need to look through the
DW_TAG_lexical_block DIEs to find the DIEs that we are interested in.
Depends on D25471
Differential Revision: https://phabricator.services.mozilla.com/D25472
--HG--
extra : moz-landing-system : lando
We record the file and line that these subroutines were inlined from.
We'll use that information to provide more coarse-grained line
information in the next patch.
Depends on D25469
Differential Revision: https://phabricator.services.mozilla.com/D25470
--HG--
extra : moz-landing-system : lando
The DW_AT_call_file attributes that we eventually want to parse from
DW_TAG_inlined_subroutine DIEs refer to the file name table stored in
the .debug_line section. To resolve those DW_AT_call_file attributes,
we need access to that table after parsing of the appropriate
.debug_line bits is done. This patch adds support for extracting that
information from the .debug_line parsing process.
Differential Revision: https://phabricator.services.mozilla.com/D25469
--HG--
extra : moz-landing-system : lando
It's the caller's responsibility to have up-to-date styles, and
nsComputedDOMStyle (which is the only of those callers that could ever care
about EffectCompositor stuff) already does it.
There's no need to explicitly update animation rules from here, since it would
only have a difference for display: none subtrees anyway (otherwise we re-use
the cached style already in the element before having a chance to process the
potential animation restyles).
My guess is that this was just copy-pasta from other functions. This doesn't
break any test.
Differential Revision: https://phabricator.services.mozilla.com/D25458
--HG--
extra : moz-landing-system : lando
There are some that only have one caller, and some slightly confusing naming.
Hopefully make it a bit clearer.
Differential Revision: https://phabricator.services.mozilla.com/D25457
--HG--
extra : moz-landing-system : lando
This switches nsFrameSetFrame's hacky frame construction codepath to operate on
the flattened tree, since it made me a bit more comfortable about it (all layout
should operate on is the flattened tree, though in this cause this should not
cause any web-observable behavior change, since <frameset> can't be a shadow
host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles
lazily in descendants of display: none elements, and even though this code
doesn't check on display: none _on the children_, the parent element should
never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the <area> elements referencing an
image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for
LazyComputeBehavior::Allow on the document element in order to check the
viewport styles propagation, since the root element can't have display: none
ancestors. But we run that code before actually constructing the doc element
containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now,
since we need to keep using it for the <body>, since the document element could
be display: none itself, and we propagate the overflow styles in that case
still. I filed https://github.com/w3c/csswg-drafts/issues/3779 to potentially
change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
--HG--
extra : moz-landing-system : lando
Some of these were unused, some of them were only used in combination with
others, so I've unified them.
In particular, Forgetful and ClearAnimationOnlyDirtyDescendants were used only
together for a very specific task (the final animation traversal), so I merged
them into something that has that name.
ClearDirtyBits was unused, so I removed along with some code that would no
longer be called.
Differential Revision: https://phabricator.services.mozilla.com/D25454
--HG--
extra : moz-landing-system : lando
After bug 1530908 changed LTO to be environment driven, the macosx64
nightly mozconfig enables LTO by setting MOZ_LTO=1. The add-on-devel
mozconfig tried to disable LTO by using --disable-lto, but the
environment variable takes precedence, leaving LTO enabled for these
builds. This pushed the build time up to be close to the max runtime for
the task, causing frequent intermittent failures.
We should 'unset MOZ_LTO' everywhere that --disable-lto was used, and
'export MOZ_LTO=1' everywhere --enable-lto was used.
Differential Revision: https://phabricator.services.mozilla.com/D26608
--HG--
extra : moz-landing-system : lando
When the test font is activated, the notification of the font configuration change
may be handled asynchronously by content processes, so that it's possible the content
process has not yet handled the update at the point when registerFont() detects the
change and returns to the test script.
(This issue becomes more acute with the upcoming shared-font-list system, where the
OS notification is not handled by the content process at all; it's only handled by
the parent process, which then notifies content processes *after* it has updated the
font list. So there's an inherent latency between the update being recognized by the
chrome process - and therefore "ready" as far as the test script is concerned - and
content processes receiving and handling the change.)
To handle this, we can explicitly wait for the width of the rendered content to change,
which will indicate that the font configuration change has been handled by the content
process.
Differential Revision: https://phabricator.services.mozilla.com/D26570
--HG--
extra : moz-landing-system : lando
This only uses cross-platform tools, so switch to running these on linux, which
cuts the runtime down from ~20m to ~3m.
Differential Revision: https://phabricator.services.mozilla.com/D1080
--HG--
extra : moz-landing-system : lando
This also switches it to use the generic toolchain build image, as
it is no longer being used exclusively by mingw builds.
Differential Revision: https://phabricator.services.mozilla.com/D24230
--HG--
extra : moz-landing-system : lando
Allow read access to /System/Library for accessing system libraries.
Depends on D26397
Differential Revision: https://phabricator.services.mozilla.com/D26626
--HG--
extra : moz-landing-system : lando
Don't swizzle the terminate method in process types that don't initialize the nsApplication.
Differential Revision: https://phabricator.services.mozilla.com/D26397
--HG--
extra : moz-landing-system : lando
This is a hack to get around Windows ccov build hangs caused by bug 1195299.
Bug 1543149 will track the investigation of the hang and removal of this hack.
Differential Revision: https://phabricator.services.mozilla.com/D26750
--HG--
extra : moz-landing-system : lando
Brian Hackett
Narcis Beleuzu
Jeff Gilbert
Mats Palmgren
longsonr
Dave Townsend
Nathan Froyd
Bobby Holley
shindli
Sebastian Hengst
Oriol Brufau
Gijs Kruitbosch
Lina Cambridge
Emilio Cobos Álvarez
Andrew McCreight
Mathieu Leplatre
Jeff Walden
Brindusan Cristian
Mike Shal
Chris Manchester
Cosmin Sabou
Jonathan Kew
Chris H-C
Tom Prince
Haik Aftandilian
Noemi Erli
Andrew Halberstadt
Syeda Asra Arshia Qadri
Andreas Farre