This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
This combines the multiple fields or variants which were previously used to
track sided types like protocol types into a single field wrapped with a
SideVariant.
This will be used in the next part to avoid the need for default constructors
for actor types allowing the proper types to be used.
Differential Revision: https://phabricator.services.mozilla.com/D168879
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
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
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
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
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
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
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
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227
Streams serialized with the default nsIInputStream serializer will be serialized
with delayedStart, meaning that when sent from the parent process to the content
process it will be serialized as a RemoteLazyInputStream.
In the specific case of SendOpenStream this causes issues, as the content
process code depends on the synchronous nature of nsIFileInputStream to allow it
to be wrapped in a SnappyUncompressInputStream, which requires a sync stream.
Relying on this property is not generally correct and only works because we know
only nsFileInputStream will be sent by the parent process. Other types of sync
streams may be received as async if they are sufficiently large, such as
nsStringInputStream.
Differential Revision: https://phabricator.services.mozilla.com/D103227
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
Jens Stutte