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
(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
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
When channel registrations aren't explicitly unregistred from JS, they're
instead unregistered when the entry object is cycle collected. When the
entries are created close to shutdown, that can leave some uncertainty as to
the order of destruction, and the WebRequestService might wind up being
destroyed before all of the entries. In that case, the registrations are
cleaned up when the hash entries hash table is being destroyed.
While that isn't strictly a problem, the entries expect to still be present in
the hash table when they're being destroyed, as a basic sanity check. This
patch ensures that we always remove entries from the hash table before it's
destroyed, so those invariants are maintained.
MozReview-Commit-ID: 5jWpFeFyjJZ
In order to allow extensions running in a content process to connect extension
filters, we need to be able to track which requests they have permissions to
modify, and which processes they have permissions to modify them from.
This interface allows us to register channels that we've dispatched webRequest
listeners for, and the TabParent (and, by proxy, content parent) we've
dispatched them to. Extensions will only be able to filter those channels, and
only from those processes.
MozReview-Commit-ID: 46HTVeQ5ndi
