These were detected by the script used to generate part 2.
MozReview-Commit-ID: VMcT154f6f
--HG--
extra : rebase_source : 2f5fc8a314302fcacac840a8dbe0ff874d518e51
It's unnecessarily general, because we only ever use
Preferences::DirtyCallback() as the callback.
And because it's no longer a callback, the patch renames DirtyCallback() as
HandleDirty().
MozReview-Commit-ID: Hl50dcxfVQq
--HG--
extra : rebase_source : 5807d2ed650466f85cd7325f2adccdc177ccb4d2
It's simple enough that having a separate function isn't helpful.
MozReview-Commit-ID: Ke9BIfp9yHU
--HG--
extra : rebase_source : 57aee451b8fd3450da4a604cefbf9fafda894b1c
Preferences.cpp has two functions named pref_DoCallback(). One of them has a
single use in the parser. This patch inlines that single use to remove the name
duplication.
MozReview-Commit-ID: HnyteQ0N5M1
--HG--
extra : rebase_source : 37a34f3fbe866eee71a7bf0bba07d9d67cc8c81d
Bug 1403843 made more things constant, but missed a few that don't
depend on the page size.
--HG--
extra : rebase_source : 036722744ff7054de9d081bde1f4c7b035fd9501
A lot of effort has been spent optimizing VCS operations for peak
performance. But not utilizing caches or volumes for the VCS store
or checkouts can undermine that work.
Let's print a warning when VCS is configured sub-optimally.
I'm pretty sure we still have some rogue tasks not using caches
or volumes. We can convert this to a fatal error once those are
fixed.
MozReview-Commit-ID: C6CT1zViy75
--HG--
extra : rebase_source : 91760250bed263c789b95d16cc0542a53ca2bfbf
This seems like a reasonable thing to enforce.
MozReview-Commit-ID: 3BZQSkwRYeN
--HG--
extra : rebase_source : 8dae62edb35202da0f0e90ddec3eacb212ada371
We introduce a per-cache .cachelog file containing important events
in the cache's history such as creation, requirements adjusting,
and utilization. If cache validation fails, we print the cache log.
If a previous task was responsible for getting the cache in a bad
state, its TASK_ID should be printed, allowing us to more easily
identify mis-configured tasks.
MozReview-Commit-ID: BJun5Hi5w0s
--HG--
extra : rebase_source : f4758741ee294a0de53882b6891b473c01463e28
- Move variable declarations to their initialization.
- Remove gotos and use RAII.
--HG--
extra : rebase_source : 9d983452681edf63593d033727ba6faebe418afe
The chunk_recycle and chunk_record functions are never called with
different red-black trees than the globals, so just use them directly
instead of passing them as argument. The functions were already using
the associated global mutex anyways.
At the same time, rename them.
--HG--
extra : rebase_source : c45bb2e584c61b458eab4343562eb3a5a64543a3
Instead of calling it with a boolean indicating whether the call was for
base allocations or not, and return immediately if it was, avoid the
call altogether.
--HG--
extra : rebase_source : abb2a3d0eaefc16efd2e828f09a330ab2a3b8b1f
Test fails when running locally:
./mach test netwerk/test/unit_ipc/test_original_sent_received_head_wrap.js
Error: cannot open file '/home/user/mozilla-central/obj-ff-dbg/_tests/xpcshell/netwerk/test/unit/test_original_sent_received_head.js' for reading at /home/icecold/mozilla-central/testing/xpcshell/head.js:648
MozReview-Commit-ID: DcOWOWlH5ch
--HG--
extra : rebase_source : 30c5e28c61adace06cd49ca216108a277e37d58d
This is needed to prevent parameter mismatch errors when using |mach try fuzzy|
from an older revision. This can happen if the parameters.yml is being
downloaded from a commit with a recently added parameter.
MozReview-Commit-ID: 4NxCM7i8B4W
--HG--
extra : rebase_source : c47de38ad295e14c80c99806ea430fa641ae2be6
When we receive animations on the compositor, we assert that either they're not
playing, or they have a resolved start and origin time.
However, on the main thread we determine if an animation is playing by checking
if it has a timeline, if it's in the correct state, and if it has a non-zero
playback rate.
The problem with this check is that if an animation has a timeline but it is
inactive, that is, its current time is null, we will not be able to get
a resolved origin time -- yet we will still report that is is playing.
This patch fixes this mismatch by treating animations with an inactive timeline
as "not playing".
The IsPlaying() method is used a number of call sites but it appears that they
all would expect an animation with an inactive timeline to be considered "not
playing". Furthermore, this makes IsPlaying() consistent with the check we do
for an active timeline in other functions such as Animation::Tick(),
TriggerNow(), SilentlySetCurrentTime(), UpdateFinishedState(),
and IsPossibleOrphanedPendingAnimation().
MozReview-Commit-ID: BQOBpHHFMoD
--HG--
extra : rebase_source : e84a50a16a61d48553610cb7ea0863f09ba86c60
Upgrade from optparse to argparse:
1. 'type' field now needs to be callable (deleted if type was 'string' as that is the default)
2. 'extend' action re-implemented for argparse
3. 'callback' action no longer exists, re-implemented as a custom argparse action (only used in buildbase.py)
4. minor api changes, e.g 'add_option' -> 'add_argument'
MozReview-Commit-ID: HcKowF13Da3
--HG--
extra : rebase_source : e5e8160d91263fb273f790dbda5e2c2b2e02eaf6
Move clear jsterm history to openNewTabAndConsole.
Switch openNewTabAndConsole to an async function (instead of using Task.async).
Switch openNewTabAndConsole consumers to async as well.
MozReview-Commit-ID: KgMXowGYIJ5
--HG--
extra : rebase_source : 1406adc1e0afca07f92118370b402e314cb51fc1
The test was very long and tested different bugs.
Splitting it make all the test case clearer.
MozReview-Commit-ID: 4z45RE3eJoC
--HG--
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_autocomplete_keys.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_autocomplete_array_no_index.js
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_autocomplete_keys.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_autocomplete_escape_key.js
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_autocomplete_keys.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_autocomplete_inside_text.js
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_autocomplete_keys.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_autocomplete_nav_and_tab_key.js
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_autocomplete_keys.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_autocomplete_return_key.js
rename : devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_autocomplete_keys.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_jsterm_autocomplete_return_key_no_selection.js
extra : rebase_source : c9c12ee909d843bf5f3b9c1312057c5552e23df8
This is needed to prevent parameter mismatch errors when using |mach try fuzzy|
from an older revision. This can happen if the parameters.yml is being
downloaded from a commit with a recently added parameter.
MozReview-Commit-ID: 4NxCM7i8B4W
--HG--
extra : rebase_source : 4d2052aae33292fbd7928a79bfedba76426206b9
IPDL generation consists of a single ipdl.py invocation on all the
*.ipdl and *.ipdlh files in the tree. Unfortunately the headers that are
generated are placed into directories corresponding to the namespaces
declared within the IDPL, and can't be determined solely based on the
input filename. As such, we have to do a quick parsing of the AST in
order to grab the namespaces and calculate the filenames for the .h
files.
The downside of this approach is that all *.ipdl/*.ipdlh files are
considered inputs for the tup backend, so editing one will perform
moz.build generation before running ipdl.py. This could be fixed by
either standardizing the generated header layout, or fixing tup to
somehow allow unspecified outputs.
MozReview-Commit-ID: DzF2ryLEsrg
--HG--
extra : rebase_source : 9297c7532b59e453dd2e985c7d2d5a1e78571893
IPDL generation consists of a single ipdl.py invocation on all the
*.ipdl and *.ipdlh files in the tree. Unfortunately the headers that are
generated are placed into directories corresponding to the namespaces
declared within the IDPL, and can't be determined solely based on the
input filename. As such, we have to do a quick parsing of the AST in
order to grab the namespaces and calculate the filenames for the .h
files.
The downside of this approach is that all *.ipdl/*.ipdlh files are
considered inputs for the tup backend, so editing one will perform
moz.build generation before running ipdl.py. This could be fixed by
either standardizing the generated header layout, or fixing tup to
somehow allow unspecified outputs.
MozReview-Commit-ID: DzF2ryLEsrg
--HG--
extra : rebase_source : b2d6ed3f7f47b2d568aea0c7e4bd476ce432181f
Andrew McCreight
Sebastian Hengst
ffxbld
Kris Maglione
Nicholas Nethercote
Boris Zbarsky
Ryan VanderMeulen
Attila Craciun
Phil Ringnalda
Mike Hommey
Gregory Szorc
Delphine Lebédel
Henrik Skupin
Valentin Gosu
Andrew Halberstadt
Andi-Bogdan Postelnicu
Paul Bone
Xidorn Quan
Haik Aftandilian
Brian Birtles
Nicolas Chevobbe
Mike Shal
Marco Bonardo