Otherwise the global ImplCycleCollectionUnlink for JS members are shadowed by mozilla::dom::ImplCycleCollectionUnlink and can't be used.
Bug 1756794 is to move all the impls to the single namespace to prevent this, but that requires verbose changes, and currently the only affected uses are from these macros.
Differential Revision: https://phabricator.services.mozilla.com/D147234
Previously this was optimized to trace only gray roots in collecting zones, but
there was a bug in that it also skipped clearing roots because this happens
before the start of GC when zones are selected for collection.
Instead, make sure we only perform this optimziation when marking.
Differential Revision: https://phabricator.services.mozilla.com/D146585
This patch won't actually build, because a few bits of code are used
for both nsIFactory::createInstance and static components, and static
components are not fixed until the next patch.
The first place is nsLoadGroupConstructor, which uses an nsIFactory
macro to create a static component constructor. (This could be worked
around by expanding the macro to the state before this patch.)
The other issue is that nsAppShellConstructor is used in an nsIFactory
on OSX, but as a static component on all other platforms. This could
be worked around by wrapping nsAppShellConstructor in an adaptor that
passes in the extra null argument to nsAppShellConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D146456
nsIFactory is binary compatible with Windows COM's IClassFactory,
but nothing seems to depend on it. This patch removes the test
for compatibility, TestCOM, and removes the lockFactory
method that isn't otherwise needed.
Differential Revision: https://phabricator.services.mozilla.com/D146386
This allows us to replace a number of magic numbers in the
WebRequestError code with automatically generated constants which are
guaranteed to be kept up to date.
This build script is able to run early enough during the build step as
generated files which take a `.jinja` file as an argument are hard-coded
to be run during the pre-export phase for Android builds. As it is just
as simple python script with no other dependencies, this shouldn't
impact geckoview build performance even when using build artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D146356
In order to get better shutdown hang reporting, we want to distinguish also the last phases, namely `XPCOMShutdownThreads`, `XPCOMShutdownMainThread` and `CCPostLastCycleCollection`.
This also makes `XPCOMShutdownNotified()` obsolete and we need to slightly re-arrange the watchdog function.
Differential Revision: https://phabricator.services.mozilla.com/D145433
The concept of a shutdown phase is meant to be a finite and named period of time where:
1. we can query if we are in or beyond a given phase
2. we may want to do a fast shutdown
3. we inform the terminator that we reached the next phase
4. if needed/wanted, we notify observers of the associated topic
5. we KillClearOnShutdown smart pointers associated with this phase
6. we do any further, phase-individual cleanup until the next phase starts
`AdvanceShutdownPhase(WithoutNotify)` now provides the functionality for 1. through 5. and must be the only place that calls `KillClearOnShutdown` in order to avoid misalignments.
In doing so, it becomes also the only caller of `MaybeFastShutdown`.
Please refer to bug 1768581 as working on this patch made us think if we should re-work the order inside AdvanceShutdownPhase.
Differential Revision: https://phabricator.services.mozilla.com/D145083
No reason these don't work on substrings.
Remove StripChars since it has an existing nsTSubstring version. Make
callers use rightly-typed characters for those.
Differential Revision: https://phabricator.services.mozilla.com/D145864
When the NS_AsyncCopy completes, there may still be outstanding
AsyncWait callbacks which have not been invoked yet, due to two
AsyncWait callbacks being registered each time Process() yields (one to
wait for the blocked stream, and the other with WAIT_CLOSURE_ONLY to
handle errors), and only one callback being needed to resume processing.
This change ensures that any outstanding AsyncWait callbacks are
cancelled, breaking references from the streams to the
nsAStreamCallback. Some streams (such as nsPipe and DataPipe) may also
leak if there are oustanding AsyncWait callbacks, due to the need to
keep the stream alive so it can be passed into the callback, which this
helps avoid.
Previously leaks were largely avoided due to the call to `Close()`
cancelling the callbacks for us, however not all callsites specify to
close the source/sink.
This should also help avoid an unnecessary dispatch after the copy
completes due to our AsyncWait callback being invoked when the
source/sink stream is closed.
Differential Revision: https://phabricator.services.mozilla.com/D146130
If we don't do this, we can encounter issues where we'll spuriously close the
stream when the last reference to the input stream is dropped while an
AsyncWait is still pending.
Differential Revision: https://phabricator.services.mozilla.com/D145672
As discovered by TSan, this member could be raced on in some edge-cases if
cloned pipe streams raced on multiple threads to be destroyed. This change
instead moves the `nsIPipe` implementation to be on a seperate type from
`nsPipe`, allowing `mOriginalInput` to no longer need to be tracked.
This technically has slightly different behaviour than the previous
implementation for JS code, as code keeping the `nsIPipe` alive will now also
be keeping the output stream reference alive directly, rather than only holding
the `nsIPipe`, meaning that `pipe.outputStream` can be read multiple times
independently without implicitly closing the underlying stream. Based on a
quick read of the few remaining uses of `nsIPipe` in JS code, I don't think
this will be an issue, and it may actually be more intuitive and consistent.
Differential Revision: https://phabricator.services.mozilla.com/D145362