ArrayView is a data structure I removed as part of the simplification of worker cancellation, as it was only used for this purpose in the entire code base. I am bringing it back now, as we are re-implementing that same behavior.
Differential Revision: https://phabricator.services.mozilla.com/D162218
This class is no longer used, after the removal from the WorkerScriptLoader. It can be removed,
unelss we want to keep it for future use. This cleanup is optional.
Differential Revision: https://phabricator.services.mozilla.com/D146305
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
There weren't that many uses of the existing typedef, so it seemed like
it might be worthwhile to just replace all uses of the previous typedef
with the stl-like one.
Differential Revision: https://phabricator.services.mozilla.com/D142705
The changes to nsTArrayBackInserter::operator= broke the builds on Windows
under some circumstances. This reverts those changes. Necessary adaptations
in the stack are made in later patch.
Differential Revision: https://phabricator.services.mozilla.com/D109276
We fixed what I think is the lone instance of writing into the (empty)
header in `SetLength` because it was causing TSan violations, so we should
be clear to make this `const`. This change is not terribly effective on its
own (cf. the `const_cast` required to make this work at all), but in the
next patch, we can rig up `sEmptyTArrayHeader` to be surrounded with "guard
pages" and make rogue accesses off the array header a little more protected.
Differential Revision: https://phabricator.services.mozilla.com/D88657
nsTArray_Impl::Assign/operator= copying from another array cause code bloat by
using ReplaceElementsAtInternal without exploiting the knowledge that the whole
array is being replaced. Since for many instances of the class template, this
is the only ReplaceElementsAtInternal call being done, this unnecessary bloats
the generated code. Apart from that, it is suboptimal at runtime due to
unnecessary checks.
Furthermore, the implementation of ReplaceElementsAtInternal may unnecessarily
relocate the existing elements before destroying them if the storage needs to
be reallocated. While this could be optimized in ReplaceElementsAtInternal as
well, it is simpler to do so in the specialized AssignInternal that is now
introduced.
Differential Revision: https://phabricator.services.mozilla.com/D86723
The mentioned array operations were implemented using SwapElements, which is a
rather generic and therefore complex method (in the sense of template
instantiation and code generation), which doesn't make use of the knowledge that
the target array is empty and does not have any allocated heap storage.
Similar to the introduction of MoveConstructNonAutoArray, a new method, MoveInit,
is introduced that uses this knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D84806
The move constructor of nsTArray_Impl (and therefore of nsTArray) was
implemented using SwapElements, which is a rather generic and therefore
complex method (in the sense of template instantiation and code generation),
which doesn't make use of the knowledge that the target array does not have
inline storage and is empty with 0 capacity. Therefore, a new specialized method,
MoveConstructNonAutoArray, is introduced that does use this knowledge. This
adds another method to maintain, but given that the move constructor is a
frequently used operation that is expected to have a small compile-time and
run-time cost (potentially used implicitly), this seems like a reasonable
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D84804
The mentioned array operations were implemented using SwapElements, which is a
rather generic and therefore complex method (in the sense of template
instantiation and code generation), which doesn't make use of the knowledge that
the target array is empty and does not have any allocated heap storage.
Similar to the introduction of MoveConstructNonAutoArray, a new method, MoveInit,
is introduced that uses this knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D84806
The move constructor of nsTArray_Impl (and therefore of nsTArray) was
implemented using SwapElements, which is a rather generic and therefore
complex method (in the sense of template instantiation and code generation),
which doesn't make use of the knowledge that the target array does not have
inline storage and is empty with 0 capacity. Therefore, a new specialized method,
MoveConstructNonAutoArray, is introduced that does use this knowledge. This
adds another method to maintain, but given that the move constructor is a
frequently used operation that is expected to have a small compile-time and
run-time cost (potentially used implicitly), this seems like a reasonable
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D84804
mozilla::ReverseIterator is required for "stashing iterators", but otherwise
std::reverse_iterator can be used and is potentially more efficient.
Also fix some other glitches in iterator type definitions.
Differential Revision: https://phabricator.services.mozilla.com/D79489
Yulia Startsev
Nika Layzell
Noemi Erli
Sebastian Hengst
Butkovits Atila
Mike Hommey
Brad Werth
Jesse Schwartzentruber
Simon Giesecke
Csoregi Natalia
Gerald Squelart
Sylvestre Ledru
Nathan Froyd
Razvan Maries