This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch was mostly[1] automatically generated. I found the files to be fixed
in this patch with the following command:
grep -r "C++; indent-tabs-mode:" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
old="/\* -\*- Mode: C++; indent-tabs-mode: nil; c-basic-offset: 4 -\*- \*/"
new="/\* -\*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -\*- \*/"
sed -i s%"^$old"%"$new"% $1
###
[1] NOTE: Nearly all of these files use 2-space indentation, so it's correct
(from a consistency perspective and a reflecting-reality perspective) that
we're reducing their "c-basic-offset: 4" down to "c-basic-offset: 2" here. The
one exception is nsDeviceContext.h, which *does* actually use 4-space
indentation right now -- so I'm leaving that file with "c-basic-offset: 4" in
its mode line. This manual change (reverting 1 character from the automated
process) is the only piece of this patch that isn't automated.
MozReview-Commit-ID: L4MbyeYSbfY
--HG--
extra : rebase_source : 8ddbe422471bfd8b0060e96fb1c8cd062f10f290
The content process stores the incoming initial gfxVars updates, which are
lazily used when the gfxVars are first initialized.
MozReview-Commit-ID: ExUVdr5xGLb
--HG--
extra : rebase_source : fd6f3e1bc4eabdd85447eff0c0fa22537747431f
When a subprocess is launched, gfxVars updates (for non-default values) are
serialized and passed on the command line, up to a limit of 1023 characters,
and ensuring it should not overflow the command line size.
When the child starts, the command line parameter is given to gfxVars, so the
updates can be used during gfxVars::Initialize(), instead of doing a sync
request to the parent.
In case the updates are not sent, or in the unlikely case the child cannot
parse them, we fallback to the sync request -- The former case should be rare
enough that a slow sync request is acceptable: It should only happen if D3D
block-list is *modified* (most people would either use the default, or just
overwrite these prefs with short strings.)
MozReview-Commit-ID: 6MoJC0fe59Q
--HG--
extra : rebase_source : cdc2e451783160c579b8fc84050e8457c600523e