This removes some unsafe/unstable code and replaces it with a new safe/stable alternative.
Note that `process::abort` is not identical to `intrinsics::abort`, since it runs global cleanups to do things like flush stderr (though neither function performs stack unwinding). I don't *think* the difference matters for our use cases.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they should not change functionality
Source-Repo: https://github.com/servo/servo
Source-Revision: 52920ed645b95a7e2ad1bb055c02f566b0943be6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bc702546691568b8f23e68257836a3bb7dad88b5
The safebrowsing files are defined in two different places with differing levels of greediness, and with different bugzilla components defined (one of which doesn't even exist any longer). Additionally, controlcenter files are defined down in a completely different section of the file, making it easy to not see it when making changes to the file.
MozReview-Commit-ID: HUr86lUmH4R
--HG--
extra : rebase_source : 2cc10de0c4d46efde210072789d0aaf9989e417e
Also remove bits of a comment, now that we support only macOS 10.9+, most of the
comment isn't relevant.
While PIE is enabled by default on macOS, this isn't true of clang on Linux.
--enable-pie can now be used with clang on Linux.
r=froydnj
MozReview-Commit-ID: rc6zJiWzLo
--HG--
extra : rebase_source : 3745175e106ea8c6be9271d8135d43ba359434c7
This removes the last uses of PR_smprintf from the tree (excluding the
security and nsprpub directories). It also fixes a related latent bug
in nsAppRunner.cpp (which was incorrectly freeing the pointer passed to
PR_SetEnv).
MozReview-Commit-ID: GynP2PhuWWO
--HG--
extra : rebase_source : c3b83c7bd08b1c222e137a00323caf5481352845
This patch shouldn't affect behavior -- it just takes a latent opportunity for
simplification and removes an unused layer of indirection. These functions were
set up to look like they took outparams, but none of the callers were using the
value left in the outparam.
MozReview-Commit-ID: LaL7YiyVYS2
--HG--
extra : rebase_source : 28466d6ab36da2e3609e7ed0fdb51618e652c7f7
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
