If dedicated thread for out-of-process WebGL exists, compositor thread tasks are not delayed by WebGL tasks.
And Bug 1712486 requests that WebGL run on non-compositor thread.
Differential Revision: https://phabricator.services.mozilla.com/D151210
`JS::{Handle/Rooted}Vector<T>` are straightforward enough and way shorter than `JS::{Handle/Rooted}<JS::StackGCVector<T>>` (too many special characters). The linter currently does not prevent the use of them, so for now let's prefer them for replacements.
Differential Revision: https://phabricator.services.mozilla.com/D150696
The function2 library uses an explicit move constructor internally,
which would trigger this checker, and cause a build failure.
Differential Revision: https://phabricator.services.mozilla.com/D145689
The function2 library uses an explicit move constructor internally,
which would trigger this checker, and cause a build failure.
Differential Revision: https://phabricator.services.mozilla.com/D145689
This patch introduces a new system for building IPDL unit tests, which is
roughly inspired by the old cxx unit test design, however designed to work with
gtest. It re-uses the existing IPDLUnitTest process type, using static
constructors only present in xul-gtest to register child actor constructors and
ProcessChild implementations to avoid bloating xul.
The IPDLUnitTest actor is used as a backchannel to communicate test failures
from the child process back to the parent process, and manage the test's async
lifecycle more reliably.
The IPDLUnitTest process also needed to have various properties about how it was
initialized adjusted:
* The IPDLUnitTest process should now always load xul-gtest when running
gtests, by using the "Self" process type and adding a DYLD_LIBRARY_PATH override
on macOS where the "Self" process type cannot be used.
* The IPDLUnitTest process now initializes minimal XPCOM, and runs a
frankeneventloop to allow it to use XPCOM event loop structures such as
SpinEventLoopUntil in tests.
* Support for creating IPDLUnitTest processes on Android was added, as these
tests had never run on android before.
Differential Revision: https://phabricator.services.mozilla.com/D137170
`MOZ_KNOWN_LIVE RefPtr<Foo> mFoo` is not treated as safe because its raw pointer
is referred with operators but they are not checked at handling `MOZ_KNOWN_LIVE`
annotation.
Additionally, when members marked as `MOZ_KNOWN_LIVE` are in the stack, they
are also not treated as safe, but they should be safe in most cases.
With these changes, `HTMLTableEditor.cpp` can get rid of a lot of
`MOZ_KnownLive` method calls.
Differential Revision: https://phabricator.services.mozilla.com/D136122
On aarch64 and x86-64 windows, the behaviour of canPassInRegisters is slightly
different than other platforms, accepting types to be passed in registers which
wouldn't be passed in registers on other platforms. This causes the lint to
behave slightly differently on that platform. This patch changes the lint to
always follow the non-win64 behaviour required by the C++ standard.
Depends on D132997
Differential Revision: https://phabricator.services.mozilla.com/D133685
The platform in question which triggered this lint being added is the windows
x86 ABI, which pre-msvc version 19.14 emitted an error when passing complex
aggregate types as parameters due to not being able to align them.
Unfortunately modern versions of Clang still have a bug in the implementation
of the post-19.14 ABI and will pass types with incorrect alignments.
This change makes the intended behaviour more clear and avoids linting against
alignments <= the pointer alignment on all platforms, as well as alignment for
types which will be re-aligned in the callee by clang.
Finally, it also adds an exception for the `std::function` stdlib type which is
16-byte aligned on macOS, but has a legal alignment on windows x86, and
therefore should not be linted against as it will behave correctly on all
platforms.
In the future, if we update to a version of clang without this ABI bug, we may
want to remove this lint entirely.
Differential Revision: https://phabricator.services.mozilla.com/D132997
This change adds an exception for stl types which implement
`std::is_trivially_move_constructible` and `std::is_trivially_destructible`, as
these are generally stable parts of the standard library type definition which
may be relied on by downstream code.
Differential Revision: https://phabricator.services.mozilla.com/D132996
This allows CustomTypeAnnotation to customize the type traversal behaviour to
allow things like opting library types out of static analysis easier. It will
be used in parts 2 and 3 to improve the non-memmoveable and non-param trait
analysis.
Differential Revision: https://phabricator.services.mozilla.com/D132995
The platform in question which triggered this lint being added is the windows
x86 ABI, which pre-msvc version 19.14 emitted an error when passing complex
aggregate types as parameters due to not being able to align them.
Unfortunately modern versions of Clang still have a bug in the implementation
of the post-19.14 ABI and will pass types with incorrect alignments.
This change makes the intended behaviour more clear and avoids linting against
alignments <= the pointer alignment on all platforms, as well as alignment for
types which will be re-aligned in the callee by clang.
Finally, it also adds an exception for the `std::function` stdlib type which is
16-byte aligned on macOS, but has a legal alignment on windows x86, and
therefore should not be linted against as it will behave correctly on all
platforms.
In the future, if we update to a version of clang without this ABI bug, we may
want to remove this lint entirely.
Depends on D132996
Differential Revision: https://phabricator.services.mozilla.com/D132997
This change adds an exception for stl types which implement
`std::is_trivially_move_constructible` and `std::is_trivially_destructible`, as
these are generally stable parts of the standard library type definition which
may be relied on by downstream code.
Depends on D132995
Differential Revision: https://phabricator.services.mozilla.com/D132996
This allows CustomTypeAnnotation to customize the type traversal behaviour to
allow things like opting library types out of static analysis easier. It will
be used in parts 2 and 3 to improve the non-memmoveable and non-param trait
analysis.
Differential Revision: https://phabricator.services.mozilla.com/D132995
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
`Layer::GetDisplayListLog()` also still contains the metion to
LayerScope to dump display list.
But this change does not remove it because it's a part of debugging display list.
If we remove it, I think we should open a new bug for it.
Differential Revision: https://phabricator.services.mozilla.com/D126512
sotaro
Narcis Beleuzu
Kagami Sascha Rosylight
Ryan VanderMeulen
Nika Layzell
criss
Mike Hommey
Molnar Sandor
Iulian Moraru
Christian Holler
Noemi Erli
Butkovits Atila
Masayuki Nakano
Jan-Ivar Bruaroey
kriswright
Csoregi Natalia
Kershaw Chang
Byron Campen [:bwc]
Andi-Bogdan Postelnicu
Tetsuharu Ohzeki
Chris Peterson
Andrew Sutherland