Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
1. Make nsINamed queriable on WrappedJSHolder.
2. Identify callers via |Cu.generateXPCWrappedJS(aCallback).QueryInterface(Ci.nsINamed).name|.
--HG--
extra : amend_source : 5d4201059f66e46c869c30a963921b6f7b91c389
This might be prematurely optimized as it uses two lists (one list of active
contexts and one list of inactive contexts) but I was really attracted by the
idea of being able to answer questions like "is any context active" by only
looking at a single context and not having to iterate the whole list every
time we needed to do anything.
It is really important that nobody touches any of the timestamps (or the
mActive member) outside of the Watchdog lock. I thought about trying to
encapsulate that data in its own class, but that felt like overkill. Let me
know if you disagree.
There are still a couple of uses of XPCJSContext::Get that probably need to be
stamped out, but I think doing so will depend on the details of how we map
JSContexts to XPCJSContext (and XPCJSRuntimes). I think that should wait for a
separate bug.
MozReview-Commit-ID: 9UZlh7Jutne
--HG--
extra : rebase_source : 039b50bc70547b03bc0724435de0a10a29fcf85e
The current code assumes it can store data about "the" XPCJSContext on the
WatchdogManager singleton. Once we have more than one XPCJSContext running
around, that won't be possible. This moves the needed data onto the
XPCJSContext itself and gives the WatchdogManager the proper context to
operate on.
MozReview-Commit-ID: AxyFKp9LmH3
--HG--
extra : rebase_source : 113e3b8986563016d43b25e753bde61f7af49291
This might be prematurely optimized as it uses two lists (one list of active
contexts and one list of inactive contexts) but I was really attracted by the
idea of being able to answer questions like "is any context active" by only
looking at a single context and not having to iterate the whole list every
time we needed to do anything.
It is really important that nobody touches any of the timestamps (or the
mActive member) outside of the Watchdog lock. I thought about trying to
encapsulate that data in its own class, but that felt like overkill. Let me
know if you disagree.
There are still a couple of uses of XPCJSContext::Get that probably need to be
stamped out, but I think doing so will depend on the details of how we map
JSContexts to XPCJSContext (and XPCJSRuntimes). I think that should wait for a
separate bug.
MozReview-Commit-ID: 9UZlh7Jutne
--HG--
extra : rebase_source : a927511fbf5a7bbdb75f616b751ec3fb51e76903
The current code assumes it can store data about "the" XPCJSContext on the
WatchdogManager singleton. Once we have more than one XPCJSContext running
around, that won't be possible. This moves the needed data onto the
XPCJSContext itself and gives the WatchdogManager the proper context to
operate on.
MozReview-Commit-ID: AxyFKp9LmH3
--HG--
extra : rebase_source : 113e3b8986563016d43b25e753bde61f7af49291
Creating and populating temporary export objects is fairly expensive. Defining
and then redefining lazy getters is sometimes even more expensive.
Caching the export objects from module imports, and immediately defining
properties from already-imported modules appears to save a considerable amount
of overhead at startup.
MozReview-Commit-ID: 2jR1i0WpIcw
--HG--
extra : rebase_source : d64e3380f290b12a004177be678abad88530bbc5
This is a purely non-functional plumbing change. Instead of passing a
SizeOfState and an nsStyleSizes a bunch of places, we pass an nsWindowSizes,
which contains both of them.
This is a necessary precursor for the next patch.
MozReview-Commit-ID: Ek03wDM50rB
--HG--
extra : rebase_source : 7b05708bd21dc4e3812ea041647fa74bb413d0b9
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is used in ways that rely on the implicit conversion
to |char*|. The patch uses get() and EqualsLiteral() calls to replace the
implicit conversions.
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
