Cargo.lock changes only, does not affect stylo. One new dependency because `brotli` split into two crates.
---
- [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 they touch Cargo.lock only
Source-Repo: https://github.com/servo/servo
Source-Revision: 487da47ea4f46a480fbc2da985a05f0fa7953e99
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9352629a943a762d7a8f62cac4c136e09cc1d87a
The old archive was uploaded with internal visibility. This was almost
certainly a mistake.
I downloaded the old archive and produced a new one and re-uploaded it to
tooltool with public visibility. I had to reproduce the archive because
tooltool won't let you promote an existing item to public.
It appears that environment state and possibly differences in the
tar command result in diverging tar archives. For example:
==> clang.orig <==
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/bin/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/include/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/lib/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/libexec/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/man/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-build/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-view/
==> clang.new <==
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/bin/
-rwxr-xr-x gps/gps 18099 2017-02-01 20:15 clang/bin/git-clang-format
-rwxr-xr-x gps/gps 6731340 2017-02-01 20:33 clang/bin/llvm-mc
-rwxr-xr-x gps/gps 2241688 2017-02-01 20:34 clang/bin/obj2yaml
-rwxr-xr-x gps/gps 17105264 2017-02-01 20:33 clang/bin/llvm-c-test
-rwxr-xr-x gps/gps 13153616 2017-02-01 20:33 clang/bin/bugpoint
-rwxr-xr-x gps/gps 49666672 2017-02-01 20:33 clang/bin/clang-3.9
-rwxr-xr-x gps/gps 52901 2017-02-01 20:15 clang/bin/scan-build
-rwxr-xr-x gps/gps 6214036 2017-02-01 20:30 clang/bin/llvm-ar
Content within should be identical. It's just the file ordering and
owner bits that are different. This shouldn't matter.
MozReview-Commit-ID: HOzNXAd7xwq
--HG--
extra : rebase_source : 92650cbd1869b744a5f6a1d3534fb512f85b32d1
If a CC takes too long (around 50 slices) or gets interrupted by a GC,
we have to finish it synchronously, which can cause a big pause. This
patch tries to avoid that by eagerly increasing the slice budget the
longer a CC goes on. It linearly increases the slice time from 5ms to
40ms as we approach the halfway point of a CC (1 second), matching GC
pauses, and then leaves it at 40ms.
MozReview-Commit-ID: 8TKZ0ZuxsUA
--HG--
extra : rebase_source : 2c46e56ecaa47242177d8cce53a208f08f5cabe2
The call that's causing the crash seems to be [1], that is, we're trying to
recreate frames for the root element, which should always have a frame created
at the initialization of the PresShell.
So the function I removed in that bug had something like the following:
if (!mDidInitialize) {
// Nothing to do here. In fact, if we proceed and aContent is the
// root we will crash.
return NS_OK;
}
Which PostRecreateFramesFor doesn't guard against (because I thought it was not
needed, per tryserver results).
Sounds a lot like we do need that check, though I'd like to have a testcase
where it happens :(
[1]: http://searchfox.org/mozilla-central/rev/3dc6ceb42746ab40f1441e1e659ffb8f62ae78e3/layout/base/nsCSSFrameConstructor.cpp#2420
MozReview-Commit-ID: Lh6SohNmmI6
--HG--
extra : rebase_source : 5b7076f86d41f5489e47ca16ac2f3620812ee9e8
We shouldn't be running pymake any more. So code to work around its
behavior is no longer necessary and can be removed. Good riddance.
MozReview-Commit-ID: AlV6ZLiA6WB
--HG--
extra : rebase_source : 56252a8d96f108fd24878e7a26f0d4ffe4a0db45
Now that mozharness is calling `mach build` to invoke the "check" target,
there are no more consumers of the "enable_pymake" config option. So we
remove it from the configs.
We also remove definitions of the "make" executable referring to pymake.
The only call sites I could find for "query_exe('make')" are in
testing/mozharness/scripts/mobile_l10n.py. So most of these definitions of
the "make" executable appear to be a cargo cult or left over from a
previous rewrite (the code we just changed to stop calling "make" wasn't
using query_exe). Since mobile_l10n.py is still using query_exe() to find
the make executable, there's a chance switching away from pymake (if this
patch even does that - I don't think we touched a config file related to
that script) could break something. I'm fine with teasing out that bug.
MozReview-Commit-ID: 7HR6ShAKcoV
--HG--
extra : rebase_source : 07c6a6f7aaab6d7fceeab46b6ca2744c964148dd
We switch mozharness to use `mach build` to invoke the "check" make
target instead of using `make` itself. Because `mach` is the interface
that everyone should use and `make` is an implementation detail.
My editor also snuck in a change to normalize a CRLF line ending.
MozReview-Commit-ID: 4gdE6oeK0Lz
--HG--
extra : rebase_source : 0bfd6503a25f6b4304b596bd59ef99294c011474
mozharness is currently making a manual `make -k` invocation. We don't
want automation calling `make` directly. So teach `mach build` to
accept a --keep-going argument that results in `make -k`.
MozReview-Commit-ID: H3lJ4r8S4vj
--HG--
extra : rebase_source : 9feb7bcaeb855254c53c5fa9d49177c5133f2773
Several years ago, joey starting writing a handful of unit tests for
primitives in our make files. IIRC a lot of the impetus behind this
work was to flush out bugs between GNU make and pymake.
AFAICT the only survivor of these tests today is check_mkdir.py. The
test is a one-off and has been a bit fragile over the years,
contributing technical debt along the way. And as part of removing the
last references to pymake in automation, it is once again showing
itself and failing in a way that has to do with the way the test
is written and not an issue with the code it is testing. Enough is
enough. This commit removes the test and eliminates the technical
debt. I don't think it will be missed.
MozReview-Commit-ID: 3OzurtFbcyD
--HG--
extra : rebase_source : 6d3cf6121c90e9c47948862b8c4117bb1d3e5afd
A more general fast path was added in bug 1355353.
MozReview-Commit-ID: HGe9WaojoYw
--HG--
extra : rebase_source : b8d99223422a95fd764ff47042df6fe68334bb89
I was able to fix the issue by only letting the background script send one error message per test. This isn't an ideal fix because it doesn't get to the bottom of why a second error message is sometimes sent, but it should be a good placeholder while the underlying issue is researched.
MozReview-Commit-ID: 21uZL3r4zVS
--HG--
extra : rebase_source : 69a64dbf2b958dc871047b149acb6682f2bd6389
<!-- Please describe your changes on the following line: -->
It was converting all angles to radians before. But other browsers preserves the angle units. Fixed that behavior.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#16594 and [Bug 1360659](https://bugzilla.mozilla.org/show_bug.cgi?id=1360659)
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 0abd5bbabd19695a5a42437dc42ab3bdf76f6150
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5a181ae79c46ceb680a59b0971e60c31b9f6e1b8
In Bug 1331915 we added Telemetry for Graphite. However, because
our Beta and Opt-In population is very skewed by locale, and we
explicitly want to understand locale-specific usage, we want to
make this item enabled by default.
MozReview-Commit-ID: GrPN0XxrIe7
--HG--
extra : rebase_source : 35c331e11fd98e099ea86d30e3efd96c5d6cdcb0
The browserContainersGroup is behind privacy.userContext.ui.enabled so have to test it according the pref state.
MozReview-Commit-ID: 5GxJJh2Mi6S
--HG--
extra : rebase_source : edae0ebb8cdb197629469db53f6583706006262b
This is a PR for https://bugzilla.mozilla.org/show_bug.cgi?id=1360776
- [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 it's for stylo.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7088969c2814688cc331d0e1385e352f76a54b5f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5a20650597f8e274c14c060b48e57aeaef3650d3
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
I expect this to improve the situation significantly in https://bugzilla.mozilla.org/show_bug.cgi?id=1360881
This is worth doing on its own, though.
Source-Repo: https://github.com/servo/servo
Source-Revision: a75fa0825c267798493b824fe7513308bd042be7
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6b7ac9715c8e33c3138d1f29a42c0e61b96db453
Matt Brubeck
Wes Kocher
Gregory Szorc
Mike Conley
Andrew McCreight
Tom Tromey
Ursula Sarracini
Emilio Cobos Álvarez
Matthew Wein
Edouard Oger
Nazım Can Altınova
Tom Ritter
Anthony Ramine
Fischer.json
Vangelis Katsikaros
Hiroyuki Ikezoe
Cameron McCormack
Sebastian Hengst
Phil Ringnalda
David Anderson
Chris Pearce
Simon Sapin
Kannan Vijayan
Bill McCloskey
Bobby Holley