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
They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
Allow using the MOZ_KnownLive function to get around it.
Use case is the following: I have an std::function member variable, and I want
that member to be able to capture `this`.
Using a strong reference creates a cycle and thus would leak. I know `this` to
always outlive the member, so it is fine to use a weak capture there.
Differential Revision: https://phabricator.services.mozilla.com/D111850
Add a reference to MOZ_NO_ADDREF_RELEASE_ON_RETURN in the message.
Use the qualified name of the function returning the object.
Differential Revision: https://phabricator.services.mozilla.com/D106143
In clang 11, the contents of `ast_type_traits` were moved to the `clang` namespace, but forwarders were kept to give a grace period for downstreams.
In this week's clang 12, the forwarders have been removed, and our builds will break.
Thanks to upstream kindly allowed this transition period, we can simply do the rename now to prepare for clang 12, and existing clang 11 builds still work.
Differential Revision: https://phabricator.services.mozilla.com/D99817
Sometimes thread names bit rot in the list because there is no checker in place to ensure they are still active. The threads I removed have either:
-Been converted to use the background thread pool
-Been removed entirely
-Been renamed
And they no longer require entries in the list.
Differential Revision: https://phabricator.services.mozilla.com/D96846
This introduces a new mangled symbol of the form FILE_<hash>. It's defined
on line 1 of each visited source file, and it's referenced in places that
the preprocessor tells us there was an #include. Both angle-bracket includes
and quote includes are supported here.
Differential Revision: https://phabricator.services.mozilla.com/D95529
In the next patch I'll want to be able to provide the entire source rather than
having visitIdentifier just use the token at `Loc`. The existing call sites
create a SourceRange from the SourceLocation and indicate (by not setting the
LocRangeEndValid flag) that the visitIdentifier function should retain it's
old behaviour of using the token to figure out the range.
Depends on D95527
Differential Revision: https://phabricator.services.mozilla.com/D95528
This extracts a relativizePath function that normalizes a file path to be
relative to the source/objdir, and returns the type of the file.
Differential Revision: https://phabricator.services.mozilla.com/D95527
I'll need to update this file for clang-12, and in order to prevent the need for adding more of these ifdefs, let's just assume they are true and remove the checks. Our codebase has been on C++17 for a while now.
Differential Revision: https://phabricator.services.mozilla.com/D95592
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045