XPC_WN_WithCall_ObjectOps and XPC_WN_NoCall_ObjectOps are both equal to
JS_NULL_OBJECT_OPS.
As a result, XPC_WN_ModsAllowed_{With,No}Call_Proto_JSClass are identical, as
are XPC_WN_NoMods_{With,No}Call_Proto_JSClass. (In both cases, modulo the class
name.)
This patch merges those identical-except-for-their-name pairs, resulting in
XPC_WN_ModsAllowed_Proto_JSClass and XPC_WN_NoMods_Proto_JSClass.
--HG--
extra : rebase_source : 64c5990fa5dd09418466ee25a24300bb9cfd3596
Add KeyframeEffectReadOnly::mTiming into the list of cycle collection to
avoid any possible memory leak.
MozReview-Commit-ID: C5mFQ7TsqC7
--HG--
extra : rebase_source : 8ee1e58d69a3becb0b8566fa3529154bb66d3064
Use the current document as the parent object of
AnimationEffectTiming(ReadOnly).
MozReview-Commit-ID: JfPLk95hsJ1
--HG--
extra : rebase_source : ee068d0eb8e26f4c1e83b87049be8060fcd27813
Currently, we have in-tree scripts that allow to build our toolchains.
We also have a taskcluster script for clang that can be used in with
manually created taskcluster tasks. I wrote a similar script for gcc a
while ago, for the same usage.
This change hooks all these up such that one can do a try push with
`-j linux64-clang` or `-j linux64-gcc` and get a toolchain built as a
result.
It also hooks things up such that changes to the toolchain build scripts
trigger those jobs as well, so as to ensure they are not broken by the
changes.
At the same time, allow to enable jemalloc 4 with --enable-jemalloc=4.
MOZ_JEMALLOC4 will be deprecated later.
This also changes the semantics for freebsd, where the system jemalloc
is used, relying on MOZ_MEMORY being unset (default on freebsd) and
MOZ_JEMALLOC4 to be set. In this new setup, MOZ_JEMALLOC4 implies
--enable-jemalloc=4, which still works because of the corresponding
changes to old-configure.
imply_option has no effect when the resolved value is None, so the same
logic can be applied when checking for unknown implied options.
This allows to imply options that may not always exist (because they are
in a configure file that is optionally included).
Ideally, it would be better not to do this, but until we have something
better than optionally included configure files for
--disable-compile-environment, this is a necessary evil.
While forgetting about it was warned about, having to add every new
environment option to wanted_mozconfig_variables is cumbersome. It turns
out there is a hackish way to make things work without that list, which,
all things considered, is not worse than the hacks around the
wanted_mozconfig_variables function, and are certainly an improvement as
it doesn't require an ever growing list of environment options.
Rust 1.8 added unwind support. but 1.9 is the first release
with i586 target support without SSE2 instructions in the
standard library, which we need for compatibility with older
machines, so we need to stay on 1.9 until it's in stable release.
This is a repack of the upstream 1.9.0-beta.1 compiler build
for i686-pc-windows-msvc hosts and both i686 and i586 targets.
MozReview-Commit-ID: Ed6ND7NE1F1
--HG--
extra : rebase_source : 82587d7c2f1798f1ceb5dab708740e2bdfb62af3
This is a repack of the upstream 1.8.0 stable compiler build
for x86_64-pc-windows-msvc hosts and the corresponding std
library.
MozReview-Commit-ID: 6vHDTQgeKBW
--HG--
extra : rebase_source : 90f7daf3defdcd0967dae4a8a2827a143e7b2b65
Astley Chen
Milan Sreckovic
Michael Froman
Kirk Steuber
Tracy Walker
Nicholas Nethercote
Brian Birtles
Kaku Kuo
Julian Hector
Oriol
Doug Turner
Tooru Fujisawa
Kartikaya Gupta
Sotaro Ikeda
Ting-Yu Lin
Boris Chiou
Bill McCloskey
Steve Fink
Andrew McCreight
Xidorn Quan
Mike Hommey
David Anderson
Jeff Gilbert
Lee Salzman
Jonathan Watt
Ralph Giles