`const T&&` parameters don't have associated storage semantics defined
for them. Previously they would end up as `StoreCopyPassByRRef`, which
might even have been intentional. Forbid them, and change the one use
case invoking it to a non-reference (becoming StoreCopyPassByConstLRef).
Additionally, there are four optional storage classes that are never
automatically selected. Two of these are never used, and a third is only
used mistakenly (...ByLRef where only ...ByConstLRef is needed). Adjust
the third's use-sites, and remove all three.
The last, `StoreCopyPassByPtr`, has more of an argument to be kept: it's
simpler to use (and, arguably, to understand) than its lambda-function
equivalent when wrapping an XPCOM method that takes an [in]-pointer
argument -- but it has only one use site in the entire codebase. Replace
and remove it, as well.
No functional changes. All deleted cases remain possible via lambda
functions fed to NS_NewRunnableFunction.
Differential Revision: https://phabricator.services.mozilla.com/D202173
`const T&&` parameters don't have associated storage semantics defined
for them. Previously they would end up as `StoreCopyPassByRRef`, which
might even have been intentional. Forbid them, and change the one use
case invoking it to a non-reference (becoming StoreCopyPassByConstLRef).
Additionally, there are four optional storage classes that are never
automatically selected. Two of these are never used, and a third is only
used mistakenly (...ByLRef where only ...ByConstLRef is needed). Adjust
the third's use-sites, and remove all three.
The last, `StoreCopyPassByPtr`, has more of an argument to be kept: it's
simpler to use (and, arguably, to understand) than its lambda-function
equivalent when wrapping an XPCOM method that takes an [in]-pointer
argument -- but it has only one use site in the entire codebase. Replace
and remove it, as well.
No functional changes. All deleted cases remain possible via lambda
functions fed to NS_NewRunnableFunction.
Differential Revision: https://phabricator.services.mozilla.com/D202173
We have been seeing the stack issue from bug 1776210, but on MacOS 10.12 Sierra. We are increasing stack size for all versions.
Differential Revision: https://phabricator.services.mozilla.com/D183611
We were using SpinEventLoopUntil to order the scans and the scan results but this seems to be overkill -- we should expect the main loop to process our tasks ery quickly. In addition, it's probably not desirable to wait before scheduling the next scan because a delay in main thread processing doesn't imply lack of movement so our update is still needed. Finally, we try to avoid SpinEventLoopUntil as much as possible.
Differential Revision: https://phabricator.services.mozilla.com/D183420
gMock objects cannot be reused after they receive calls to the mocked functions. This patch changes the test to establish all of the mock expectations upfront for each network-change notification before running it. It uses gMock Sequence objects and a checkpoint to maintain (partial) temporal order.
Differential Revision: https://phabricator.services.mozilla.com/D180622
Simplifies the concurrent operations of wifi scanning and reduces the
frequency in common cases. Wifi scanning when on mobile is reduced from
every 5 seconds to every minute. Wifi scans will also happen whenever
a new listener is registered.
Differential Revision: https://phabricator.services.mozilla.com/D176200
Reorganizes the wifi-scanning code and makes more of it platform-generic
to ease the transition from polling the wifi to usually scanning only on
network changes. This is essentially just moving files/code around and
promoting nsWifiMonitor::DoScan to be platform-independent.
Differential Revision: https://phabricator.services.mozilla.com/D176199
Simplifies the concurrent operations of wifi scanning and reduces the
frequency in common cases. Wifi scanning when on mobile is reduced from
every 5 seconds to every minute. Wifi scans will also happen whenever
a new listener is registered.
Differential Revision: https://phabricator.services.mozilla.com/D176200
Reorganizes the wifi-scanning code and makes more of it platform-generic
to ease the transition from polling the wifi to usually scanning only on
network changes. This is essentially just moving files/code around and
promoting nsWifiMonitor::DoScan to be platform-independent.
Differential Revision: https://phabricator.services.mozilla.com/D176199
Simplifies the concurrent operations of wifi scanning and reduces the
frequency in common cases. Wifi scanning when on mobile is reduced from
every 5 seconds to every minute. Wifi scans will also happen whenever
a new listener is registered.
Differential Revision: https://phabricator.services.mozilla.com/D176200
Reorganizes the wifi-scanning code and makes more of it platform-generic
to ease the transition from polling the wifi to usually scanning only on
network changes. This is essentially just moving files/code around and
promoting nsWifiMonitor::DoScan to be platform-independent.
Differential Revision: https://phabricator.services.mozilla.com/D176199
This flag is not supported by most event targets and can have unexpected
side effects (namely spinning a nested event loop). All consumers have
been replaced with a new function which is more explicit about this side
effect.
Differential Revision: https://phabricator.services.mozilla.com/D173985
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This replaces deprecated classes, except in the one case where we're
purposely using the deprecated class until it's actively removed.
Differential Revision: https://phabricator.services.mozilla.com/D159368
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
Use a larger stack size on macOS 13 for the Wifi monitor thread to accommodate Core WLAN code allocating 217K+ on the stack.
Differential Revision: https://phabricator.services.mozilla.com/D152555
