We fail bindgen layout tests on 32 bit because FontComputationData does not accurately reflect the size/alignment of the rust-side replacement.
We move it to the end so that alignment is more straightforward, and
use a NonZero enum so that the representation can be more accurately
handled on the C++ side.
r=emilio https://bugzilla.mozilla.org/show_bug.cgi?id=1382190
Source-Repo: https://github.com/servo/servo
Source-Revision: a64f085ee0cc3d526dd7531ce132c32c2e10b3f5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2581c78c4b627ff65def07226ea1976819d63a83
The nexus.xml included in this patch is the result of starting Nexus
and manually adding the jcenter proxy repository using the Nexus web
administration interface (all in a Docker container). I know of no
way to do this configuration incrementally without the web interface.
The diff between new and the default generated configuration is a
single new <repository>..</repository> element.
MozReview-Commit-ID: 2Bg5qX41pHB
--HG--
extra : rebase_source : c945acabcedd98439a0ca0e26251bab1a41de197
extra : source : 9b794a7fc266da1ae81afd795f91e72d04bbc992
We overwrites DrawResult returning from
nsCSSBorderImageRenderer::CreateBorderImageRenderer by the returning value of
DrawBorderImage, which is not right.
MozReview-Commit-ID: 1EeqU5hLyln
--HG--
extra : rebase_source : a78aa841795afa830b66da650a619f46230b10dd
There are a few places where we walk commit ancestry looking for things
attached to a specific revision. Because the repository name is attached
to the index path and because a revision can exist in multiple
repositories, we often have to perform N index lookups to find a result
for a specific revision. This is inefficient.
To facilitate faster index lookups by revision, we introduce a new route
that doesn't contain the repository name. In theory, we should be able
to do this globally - for all repos. However, the configuration of
tasks can vary significantly by repo. So e.g. a linux64 build on
"central" is sufficiently different from a linux64 build on "beta" or
"release." For that reason, this commit takes the conservative
approach and only defines a shared route for repositories with a similar
configuration: the "trunk" repositories.
MozReview-Commit-ID: 8rIgUbzW4eL
--HG--
extra : rebase_source : 301ed36424e0c69c25e63121809afb96ca327edc
extra : source : 543c503f745c89360398fd3207ddaea5c262a807
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
--HG--
extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3
We now store HG or GIT in substs. We don't need to search for
binary paths.
MozReview-Commit-ID: 8sSgPNLok9M
--HG--
extra : rebase_source : bc51087bcb9f2a723e27f240dd06a88540f6d8a8
We now have a variable in config.status for recording the checkout
type. These helper functions for determining if we're Mercurial or Git
can now be one-liners.
As a bonus, we no longer do I/O as part of this function.
MozReview-Commit-ID: HT9sbOhDEkf
--HG--
extra : rebase_source : 8b53b5f50d14c0bdd4ef3dc7b190314af80a76f0
For reasons unknown to me, Windows CI is periodically failing to find
the Mercurial binary.
In addition, we've also reimplemented various VCS logic throughout
the build system. There is room to cut down on code complexity by
e.g. recording VCS info in configure instead of determining it
at run-time.
Also, for forensic purposes it is sometimes desirable to know which
VCS tool is in use by a build and which version of that tool is being
used.
This commit adds VCS type detection, binary searching, and version
resolution to configure.
substs now contains VCS_CHECKOUT_TYPE, HG, and GIT, which can be
consulted by downstream consumers.
If the Mercurial or Git versions could not be resolved, all variables
are not set. Otherwise, VCS_CHECKOUT_TYPE and one of HG or GIT is set.
If MOZ_AUTOMATION is set, we require that the VCS info be resolved.
This helps prevents weirdness in automation due to unexpected
environment configuration.
MozReview-Commit-ID: AMLy0Hfx5rD
--HG--
extra : rebase_source : edef9165d32dc47308a14b0fbabce3c1d3d28176
And include code to work around a bug on older Python versions.
MozReview-Commit-ID: 4pBnMQQJOGB
--HG--
extra : rebase_source : 6f7c5784230bd37b3496b9bb1781e8d342f741b4
We're about to make MOZ_AUTOMATION more strict about things like having
a source checkout.
The whole point of build-sm-package.sh is to verify that SpiderMonkey
can be built outside of Mozilla's source repo and automation from a
standalone package. Since the presence of MOZ_AUTOMATION can influence
so much behavior in the build system, unset it so that the job
tests a !Mozilla environment more accurately.
MozReview-Commit-ID: EMfyLKfY0uU
--HG--
extra : rebase_source : 3632a9abf9fac3f916ed9043f30d4b6aa4abb390
Avoid the confusing state of "Stylo: true (disabled by build)" by also checking
the build constant _and_ the pref / env var together.
MozReview-Commit-ID: jTK66cWcyv
--HG--
extra : rebase_source : 54e158ed4f3dbde27e410aa0a59fcac44c383db3
Bug 1381521 and bug 1380465 were opened to investigate and re-enable these tests.
MozReview-Commit-ID: KbiDfqfF0ht
--HG--
extra : rebase_source : c5479538c35a9698c214d463fb59d7ded4128e13
Some tests were using "secret" APIs to get at telemetry knowledge from various
processes in various ways. Adjust them so that they work with the new ways of
doing things.
MozReview-Commit-ID: 2iBL00HVGyg
Previously we assumed count histograms were always present in payloads.
This was an erroneous assumption as count histograms were only 0 if they were
session histograms, or if they were from subsession histograms from subsessions
_after_ a subsession when they held a non-0 value.
So let's just treat count histograms as normal histograms from now on, without
any of this "sometimes 0" nonsense. This simplifies the code, tests, and our
understanding... and _should_ have few/zero downstream effects since the
existing behaviour was so poorly-understood (though exactly tested).
MozReview-Commit-ID: BH108ksygGw
TelemetrySession's getKeyedHistograms asks for each keyed histogram
individually. This is inefficient and doesn't work well with the storage
refactor.
So, plumb through a subsession keyed histogram snapshot API and convert
TelemetrySession over to using it.
MozReview-Commit-ID: Af9dTqw99UA
Previously we were doing bad string manipulation nonsense. Now when asked for
snapshots C++ can return a properly-formated Object tree.
MozReview-Commit-ID: HAvIbgzUvMU
Previously we used the base::StatisticsRecorder object for storage by name.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
In this re-write, we instead introduce the following lookup paths (managed in TelemetryHistogram.cpp):
- Main storage:
- (histogramId, processId, sessionOrSubsession) -> Histogram*
- (histogramId, processId) -> KeyedHistogram* (this handles subsessions internally)
- Lookup:
- (histogramName) -> histogramId
- (HistogramID) -> bool (is recording enabled for this histogram?)
This is wrapped with a few lookup functions.
This also allows us to keep HistogramIDs in the JS histogram instances now, instead of pointers to Histogram instances.
That means Histogram instance life-time management is now properly contained inside TelemetryHistogram.cpp.
MozReview-Commit-ID: 5yijGv7mc89
- A histogram name identifies a set of histogram instances, for which storage and lookup will be handled in TelemetryHistogram.cpp.
So we remove the names from histogram code.
- Various unused macros in the header are removed.
- Remaining traces of StatisticsRecorder are removed from the Histogram class code.
- Some unused methods are dropped that were about printing histograms to ASCII etc.
MozReview-Commit-ID: BF2rLSpKOJ8
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
This should be a straightforward performance improvement in pages with lots of CSS property values that the parser does not understand.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes do not require tests because there's no functional difference.
Source-Repo: https://github.com/servo/servo
Source-Revision: b70cbeb84caf5ec4a90a900fc5d4082989044acd
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 18e9fcafa9b8e8137b3991331effc2a629ff3e88
Manish Goregaokar
Wes Kocher
Nicholas Nethercote
Jeff Gilbert
Shane Caraveo
JW Wang
Nick Alexander
Sylvestre Ledru
cku
gasolin
Gregory Szorc
Chenxia Liu
jwu
Edouard Oger
J. Ryan Stinnett
Mike Conley
Isaac Schemm
Ehsan Akhgari
Chris H-C
Georg Fritzsche
Aaron Klotz
Josh Matthews