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
Otherwise the serialisation wouldn't roundtrip with the new syntax, which fixes
the position of <overflow-position>.
Also make Servo and Gecko agree on whether to serialize "unsafe".
MozReview-Commit-ID: L3GSMk5pZ3F
Otherwise the serialisation wouldn't roundtrip with the new syntax, which fixes
the position of <overflow-position>.
Also make Servo and Gecko agree on whether to serialize "unsafe".
MozReview-Commit-ID: L3GSMk5pZ3F
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: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and
the strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and the
strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
MozReview-Commit-ID: AduCIaDIzGG
--HG--
extra : rebase_source : ee2a20921a17b9091b60a5d9e389a6c6f2fa192b
We were getting the proper app units value for transform matrix offset before
Bug 1384656. But after that bug we started using GetCalcValue() method and
it wasn't converting length to app units and this was cousing to miscalculate
translate functions in transform property.
MozReview-Commit-ID: HHlrSg00252
--HG--
extra : rebase_source : dfc96f7905a8b501c0427519bbe5c2cb5010424e
CSSparserImpl::ParserShadowItem stores shadow items in a different order that
does not match the order we use when serializing computed shadow items.
The items order of storing by parser:
<length> <length> <length> <length> <color> <inset>
The items order of serializing:
<color> <length> <length> <length> <length> <inset>
Spec of this serialized order is as follow:
5c46d78107
This patch will shuffle the order of this items in the shadow array when
serializing it.
MozReview-Commit-ID: CIawpYKKIRy
--HG--
extra : rebase_source : 9b4f5d20543980baa45c07c950fa0baa59d9cc93
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
