This is the same as the other patch, except that it is applied to the
case where the QI returns an nsresult.
In addition, I marked the WithError helper class as being stack-only.
Depends on D7553
Differential Revision: https://phabricator.services.mozilla.com/D7554
--HG--
extra : moz-landing-system : lando
This patch adds a static assert to enforce that do_QueryInterface is
not used to go from a class to a base class, because that can be done
more efficiently via a static_cast. This is done by putting the type
of the source into the nsQueryInterface type. Once that is done, it is
easy to check the source and destination type. This has to be done
carefully so that in non-DEBUG builds, where NSCAP_FEATURE_USE_BASE is
defined, we don't generate any additional code.
The first step is to rename nsQueryInterface to
nsQueryInterfaceISupports. In DEBUG builds, I then add a new subtype
nsQueryInterface<T>, where T is the type of the object we are going to
QI. This class is a thin wrapper around nsQueryInterfaceISupports that
only forwards operations to the base class.
The main bit of trickery here is PointedToType<T>, which is needed to
get the type parameter for nsQueryInterface. This dereferences the
type, gets the address of it, then does RemovePointer. This is needed
because a wide variety of pointer types are passed in to
do_QueryInterface, including RefPtr<>, nsCOMPtr<>, raw pointers, and
OwningNonNull<>. PointedToType<RefPtr<T>> is equal to T,
PointedToType<T*> is equal to T, and so on.
In NSCAP_FEATURE_USE_BASE builds (opt), we only use
nsQueryInterfaceISupports, but in debug builds we use
nsQueryInterface<> where possible. The latter is also used for the
nsCOMPtr<nsISupports> overload, because we can always QI to
nsISupports, because that is sometimes used for canonicalization.
Another gross bit is that Assert_NoQueryNeeded can no longer use
nsCOMPtr<>, because it works by QIing T to T, which is banned by the
static analysis. Instead I had to reimplement it by hand.
Depends on D7527
Differential Revision: https://phabricator.services.mozilla.com/D7553
--HG--
extra : moz-landing-system : lando
This saves one word per static atom, per process.
The `nsGkAtoms` change is only a small part of this commit.
In regen_atoms.py:
- There is now only one link name per platform: nsGkAtoms::sAtoms[].
- But there is a new constant per atom, giving the index into
nsGkAtoms::sAtoms[].
- And the `atom!` macro for each atom indexes into nsGkAtoms::sAtoms[] using
the index constant.
- A couple of `*mut` pointers are now `*const`.
Elsewhere, the `(nsStaticAtom*)` casts within the `AppendElement()` calls are
necessary to avoid link errors, presumably due to some template instantiation
wrinkle.
--HG--
extra : rebase_source : 629642e708c8bc6e27d6057beae5f35955fdd837
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when
A is a subclass of B. There's no reason to not allow this, and RefPtr
already supports this.
Differential Revision: https://phabricator.services.mozilla.com/D7226
--HG--
extra : moz-landing-system : lando
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when
A is a subclass of B. There's no reason to not allow this, and RefPtr
already supports this.
Differential Revision: https://phabricator.services.mozilla.com/D7226
--HG--
extra : moz-landing-system : lando
If a class A is derived from a class B, then an instance of A can be
converted to an instance of class B via a static cast, so QI is not
needed. QIs are slower than static casts.
TestCallTemplates seems to be testing that CallQueryInterface compiles
even if the first argument's class is only ambiguously castable to
nsISupports, so I changed the second argument to be a class unrelated
to the concrete class.
I also removed some useless null checks on the return value of new.
Differential Revision: https://phabricator.services.mozilla.com/D6838
--HG--
extra : moz-landing-system : lando
Presumably the commit that introduced `aStringOffset` could have removed this,
but overlooked it.
--HG--
extra : rebase_source : 176f14ce01c18ed4c83892d2b7a9e7a54fb5c836
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
nsGkAtoms.h has a big comment explaining how static atom definitions get
expanded by macros. This comment was very useful when there were multiple
sources of static atoms and their definitions used macros a lot. But bug
1482782 combined all the static atom sources into nsGkAtoms and removed a lot
of macro use. So now the comment is now something of a hindrance, duplicating
quite a bit of the code (and not entirely accurately).
This commit removes the big comment, and moves the still-useful parts inline
with the code. This makes things much easier to follow.
This commit also reformats some of the remaining macros so they are easier to
read.
--HG--
extra : rebase_source : 4377be2fa0edc4ea1f592985ded89acbb76fb104
In TestEventTargetQI.cpp, nsIThreadPool is a subclass of
nsIEventTarget, so we cannot QI from the former to the latter once
trivial QIs are banned. However, we still want to check if a QI to
nsIEventTarget does something, so I added an intermediate cast up to
nsISupports, and then QI from there. I wrapped that all up in a
templated function, because the code is a bit ugly, and used it
everywhere for uniformity, even though it is not always needed.
I fixed TestCOMPtr.cpp in the same way, by casting up to nsISupports.
Differential Revision: https://phabricator.services.mozilla.com/D6855
--HG--
extra : moz-landing-system : lando
This doesn't fix the problem, but at least moves the resulting assertion
closer to the problematic caller, and makes it easier to diagnose.
Differential Revision: https://phabricator.services.mozilla.com/D7042
--HG--
extra : rebase_source : 4a016d1dce77a269b886467c9343dab125079a8f
extra : amend_source : 4e9133e70932f382e0b5df9e487978b95d05781b
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : source : 5f870621361012ba459943212d8c68a9ff81cb16
extra : intermediate-source : 89a0c0874d400dd324df6fc3627c0c47d130df19
extra : histedit_source : bbd7900e3d754bde925a411c10aa30a1d6e22edd
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
These maps hold strong references which complicate nsThread lifetime handling
considerably, and only have a couple of fringe uses. We have a linked list of
active threads that the thread manager can use for its internal enumeration
purposes, and the external uses are easily done away with, so there doesn't
seem to be much reason to keep the map around.
MozReview-Commit-ID: x7dsj6C4x8
--HG--
extra : rebase_source : 897e2d32d1dfee24d51459065925fb9b41fa543a
extra : source : 5f870621361012ba459943212d8c68a9ff81cb16
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
Ehsan Akhgari
Myk Melez
Haik Aftandilian
Nathan Froyd
Ryan Hunt
Tim Nguyen
Andrew McCreight
Nicholas Nethercote
Andrea Marchesini
Jonathan Watt
Gurzau Raul
Brindusan Cristian
Narcis Beleuzu
Jonathan Kew
Gabriele Svelto
Ciure Andrei
Stephen A Pohl
Coroiu Cristina
Bogdan Tara
Kris Maglione
Jon Coppeard