Manual changes to make all refcounted types be marked as `nullable` after the
changes in part 1a. This was done without any investigation into whether the
actual types want to be nullable, in order to avoid code changes.
Differential Revision: https://phabricator.services.mozilla.com/D168889
These are the IPDL compiler changes to make all refcounted types be considered
NotNull by default, building on the changes from bug 1607634.
Existing uses of IPDL refcounted types will be marked as nullable in part 1b.
Differential Revision: https://phabricator.services.mozilla.com/D168888
The code changes required for this will be in part 4b. The code is designed to
be generic as it will also be used for RefCounted types in a future patch. This
replaces the manual checking which was previously done in struct and union
serializers for non-nullable actor members.
Differential Revision: https://phabricator.services.mozilla.com/D168886
The idea behind this specialization is to provide the members which would be on
SideVariant<..> on NotNull<SideVariant<..>>, similar to how pointer-like
methods are available on `NotNull<T>`. This makes the type more ergonomic to
use from callers.
In the next part, this will be used for non-nullable actor members in IPDL
structs and IPDL unions.
Differential Revision: https://phabricator.services.mozilla.com/D168885
For now, this implementation is based on the implementation of the underlying
type, with extra checking that the value is not null before wrapping and
returning.
We may want to swap things around in the future so that types like RefPtr<T>
are deserialized using NotNull<T*> or similar, so that the unnecessary
serialization overhead of tracking nullness is unnecessary, however that is not
implemented in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D168884
This change allows callers of ReadSequenceParam to return a
Maybe<output_iterator> rather than a T* which will be used to fill the
resulting sequence. Both STL collections and std::array have iterators like
this, which can be returned from these methods without dramatically changing
the signature to support types without default constructors.
For types which support output iterators, they will be used for any type
without a trivial default constructor to avoid unnecessary constructor calls
and initialization when deserializing.
Differential Revision: https://phabricator.services.mozilla.com/D168882
Previously, we would always generate a default constructor for IPDL structs
which explicitly initializes every member. This would require members to have
default initializers statically. With the new approach, each member is
individually wrapped with a template parameter which will try to ensure value
initiaization, and the default constructor is implemented with `= default;`.
The default constructor will produce a warning on clang if it is implicitly
deleted, so that warning is also suppressed.
Differential Revision: https://phabricator.services.mozilla.com/D168881
This builds on top of the work in bug 1775062, by using this new signature
everywhere, including IPDL struct members and in/outparams for IPDL messages.
This is done with relatively minimal changes by using two bindings, one of
which is a reference.
Differential Revision: https://phabricator.services.mozilla.com/D168880
This will be useful after part 3 where it will be used as part of implementing
Read based on Maybe for IPDL structs. Without this change, we'd need to copy to
construct an IPDL struct containing a non-default-constructable type.
Differential Revision: https://phabricator.services.mozilla.com/D169268
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 is done by changing the formatting of QualifiedIds in the compiler
to include a leading `::`, anchoring the path in the global namespace.
This means that the generated code will fail to recognize imports by
relative paths, as they will not be found in the correct namespace.
This required no longer using QualifiedId in TypeSpec, as that type is
generally used for local types in IPDL, which are never qualified in a
namespace (only `using` statements actually support being qualified). As
part of this, I also removed the unnecessary wrapper TypeSpec from using
statements, which was never used.
Finally, this also required changing how we handle builtin imports for
the C primitive types, as these types (such as `int`, `bool`, or
`double`) are special keywords, and can't be named in the global
namespace. They are now given a new builtin type name for C builtins,
and defined separately from other using statements.
This change also means that typedefs will now appear in generated code
for types in the global namespace, but this is required to double-check
that the type is actually in the global namespace.
Differential Revision: https://phabricator.services.mozilla.com/D168878
This defines MOZ_CONTENT_TEMP_DIR to make it easier to track this in the code.
It also uses this to guard some Linux specific uses.
Differential Revision: https://phabricator.services.mozilla.com/D168596
When the fork server is enabled, not all IPC child processes are children of
the fork server; currently, process types other than content processes
are still spawned directly. This means that we need to `waitid` or
`waitpid` them when they exit in order to not leak zombie processes.
Specifically, we can just try to `waitid` the process, and then if that
fails with `ECHILD` we can assume it was a fork server child and fall
back to the previous `kill(pid, 0)` workaround. This patch does that,
but only if the fork server is active; otherwise we maintain the current
behavior of only waiting for child processes directly.
Differential Revision: https://phabricator.services.mozilla.com/D168756
When the fork server is enabled, not all IPC child processes are children of
the fork server; currently, process types other than content processes
are still spawned directly. This means that we need to `waitid` or
`waitpid` them when they exit in order to not leak zombie processes.
Specifically, we can just try to `waitid` the process, and then if that
fails with `ECHILD` we can assume it was a fork server child and fall
back to the previous `kill(pid, 0)` workaround. This patch does that,
but only if the fork server is active; otherwise we maintain the current
behavior of only waiting for child processes directly.
Differential Revision: https://phabricator.services.mozilla.com/D168756
Tests for about:memory doesn't know about utility processes. Make sure
to hide the utility process reporter when needed.
Differential Revision: https://phabricator.services.mozilla.com/D167662
Previously it was a property that all types could have, which was
incorrect, as only the UniquePtrType IPDLType could ever be a UniquePtr.
This changes that logic to make it more consistent with other IPDL
Types.
This also removes the check for a UniquePtr type attached to a `using`
statement, as the type can never be an IPDL type in that situation.
Differential Revision: https://phabricator.services.mozilla.com/D168746
Make sure that the geolocation utility process restarts for georequests that arrive after a crash. This tests process behavior regardless of whether or not the OS is set to allow geolocation (and in automation, it is not).
Depends on D162944
Differential Revision: https://phabricator.services.mozilla.com/D162945
Adds a new type of utility process that is set up to handle Windows OS objects. We are adding this process type to run Windows geolocation APIs but more services are expected to be included in it. The ILocation APIs have a race condition that would otherwise crash the main process. The ILocation work is in a later patch in the series.
Depends on D155017
Differential Revision: https://phabricator.services.mozilla.com/D155018
This patch adds the ability for Windows on ARM to launch either x86 or
ARM Widevine plugins. It also adds the ability for Windows on x86 to
refuse ARM binaries in case, for example, a profile is transferred
between machines.
Overall this should be a non-functional change for users at the time of
landing. It does however allow us to ship the ARM Widevine plugin to
Windows ARM users to workaround a plugin crash with the x86 Widevine
plugin. This only affects Windows 10 users (Windows 11 works fine).
Differential Revision: https://phabricator.services.mozilla.com/D167634
This patch implements a number of cleanups for how send semantics are
represented in IPDL types.
1. needsMoreJuiceThan is inlined.
2. convertsTo is renamed to sendSemanticsSatisfiedBy to be more descriptive,
and is no longer a class method.
3. nestedRange, sendSemantics and the methods that operate on them
are moved from IPDLType to a new class, which MessageType and
ProtocolType now inherit from.
4. IPDLType.hasReply has been inlined into MessageType.hasReply.
Differential Revision: https://phabricator.services.mozilla.com/D167836
Make sure that the geolocation utility process restarts for georequests that arrive after a crash. This tests process behavior regardless of whether or not the OS is set to allow geolocation (and in automation, it is not).
Depends on D162944
Differential Revision: https://phabricator.services.mozilla.com/D162945
Adds a new type of utility process that is set up to handle Windows OS objects. We are adding this process type to run Windows geolocation APIs but more services are expected to be included in it. The ILocation APIs have a race condition that would otherwise crash the main process. The ILocation work is in a later patch in the series.
Depends on D155017
Differential Revision: https://phabricator.services.mozilla.com/D155018
Tests for about:memory doesn't know about utility processes. Make sure
to hide the utility process reporter when needed, and count the number
of living processes, also when needed.
Differential Revision: https://phabricator.services.mozilla.com/D167662
Make sure that the geolocation utility process restarts for georequests that arrive after a crash. This tests process behavior regardless of whether or not the OS is set to allow geolocation (and in automation, it is not).
Depends on D162944
Differential Revision: https://phabricator.services.mozilla.com/D162945
Adds a new type of utility process that is set up to handle Windows OS objects. We are adding this process type to run Windows geolocation APIs but more services are expected to be included in it. The ILocation APIs have a race condition that would otherwise crash the main process. The ILocation work is in a later patch in the series.
Depends on D155017
Differential Revision: https://phabricator.services.mozilla.com/D155018
Make sure that the geolocation utility process restarts for georequests that arrive after a crash. This tests process behavior regardless of whether or not the OS is set to allow geolocation (and in automation, it is not).
Depends on D162944
Differential Revision: https://phabricator.services.mozilla.com/D162945
Adds a new type of utility process that is set up to handle Windows OS objects. We are adding this process type to run Windows geolocation APIs but more services are expected to be included in it. The ILocation APIs have a race condition that would otherwise crash the main process. The ILocation work is in a later patch in the series.
Depends on D155017
Differential Revision: https://phabricator.services.mozilla.com/D155018
Make sure that the geolocation utility process restarts for georequests that arrive after a crash. This tests process behavior regardless of whether or not the OS is set to allow geolocation (and in automation, it is not).
Depends on D162944
Differential Revision: https://phabricator.services.mozilla.com/D162945
Adds a new type of utility process that is set up to handle Windows OS objects. We are adding this process type to run Windows geolocation APIs but more services are expected to be included in it. The ILocation APIs have a race condition that would otherwise crash the main process. The ILocation work is in a later patch in the series.
Depends on D155017
Differential Revision: https://phabricator.services.mozilla.com/D155018
Tests for about:memory doesn't know about utility processes. Make sure
to hide the utility process reporter when needed, and count the number
of living processes, also when needed.
Differential Revision: https://phabricator.services.mozilla.com/D167662
As with the socket process, we can't automated test that the block works in the GPU process, but I manually verified this. I did add an automated test that ensures blocking something in the GPU process doesn't block it in other processes.
Differential Revision: https://phabricator.services.mozilla.com/D167399
As with the socket process, we can't automated test that the block works in the GPU process, but I manually verified this. I did add an automated test that ensures blocking something in the GPU process doesn't block it in other processes.
Differential Revision: https://phabricator.services.mozilla.com/D167399
Depending on the ordering includes and the direction of the wind, ipc:: can cause mozilla::ipc:: vs mozilla::dom::ipc:: ambiguity errors.
Differential Revision: https://phabricator.services.mozilla.com/D166422
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
Alexandre Lissy
Iulian Moraru
Nika Layzell
Harveer Singh
Andreas Pehrson
Sean Feng
Marian-Vasile Laza
Jed Davis
Csoregi Natalia
Bob Owen
Cristian Tuns
Olli Pettay
Andi-Bogdan Postelnicu
Norisz Fay
Andreas Farre
Emilio Cobos Álvarez
Stephen A Pohl
David Parks
Andrew Osmond
Jens Stutte
Andrew McCreight
Narcis Beleuzu
Sandor Molnar
Otto Länd
Chris Martin
Greg Stoll
Cosmin Sabou
Eden Chuang
Noemi Erli
Nicolas Silva
Yulia Startsev