Like with e.g. --with-system-zlib in bug 1641760, all supported versions
of libpng now have a pkg-config file, so use that instead of the manual
checks.
Differential Revision: https://phabricator.services.mozilla.com/D133796
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
Also updates the docs on how to update the glean_parser in-tree.
Also adds a `no_lint` exception to test pings to avoid breaking the
build.
Differential Revision: https://phabricator.services.mozilla.com/D133077
We're currently omitting a lot of them. This requires reverting a few
more patches that were followups for llvmorg-13-init-8182-gc2297544c047.
Differential Revision: https://phabricator.services.mozilla.com/D133318
We separate the patchset from the per-platform configuration, which
will ensure we keep the same patchset across them (spoiler alert: we
weren't).
Also, as most builds are PGO, use that in per-platform configurations,
and add an override config that sets it back to 2-stages for the
builds we don't want to PGO.
Differential Revision: https://phabricator.services.mozilla.com/D133317
- stage 1 is building clang with whatever compiler is available
- stage 2 is building clang with the clang built during stage 1
- stage 3 is building clang with the clang built during stage 2. It's
only useful when it's actively compared against stage 2, or when
there's a stage 4.
- stage 4 is building clang with the clang built during stage 3, with the
profile generated during stage 3, when stage 2 produced a clang with
instrumentation enabled.
We're not actively comparing the output of stage 2 and 3 when not doing
PGO, so it's not useful to do 3-stage builds.
Differential Revision: https://phabricator.services.mozilla.com/D133314
Rename it to revert-$(git describe a478b0a199f4).patch, and reorder
reversal patches so that newest patches are reverted first. It does
not matter right now because there are no inter-dependencies between
patches, but eventually, it will happen, and consistency will be
helpful.
Differential Revision: https://phabricator.services.mozilla.com/D133313
We had three versions:
- one that is unused but has a header explaining why the patch is there,
and has the regular `revert-$(git describe 2a078c307204).patch` name.
- one that is applied to trunk that was adapted to clang-trunk when
trunk was 13 and that retained the name with a `-trunk` suffix.
- one that is applied to clang 13, is identical to the one for trunk,
and has 13 instead of 12 in its name.
We only need one of them.
Differential Revision: https://phabricator.services.mozilla.com/D133312
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
In bug 1736970, we reverted an upstream change that was causing
non-determinism. In the meantime, I was able to reduce the problem to a
small C++ file, and from there, upstream was able to come up with a
straightforward actual fix.
Differential Revision: https://phabricator.services.mozilla.com/D133013
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
We only need a workdir-scoped state_dir when an on-disk virtualenv will
be created for the Mach site.
This change defers the resolution of the state_dir until we know that a
VENV will be created.
Also modify "telemetry.py" so that it isn't creating a
scoped state-dir to compare "sys.executable" against.
Differential Revision: https://phabricator.services.mozilla.com/D132706
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
Without normalization, the Windows SDK dirs are usually like
`c:/Program Files (x86)/Windows Kits/{8.1,10}`, which fails because
the build system (really, `cc-rs`) doesn't handle spaces in paths.
Differential Revision: https://phabricator.services.mozilla.com/D132287
I enabled -Wshadow-uncaptured-local warnings in bug 1718408 because the flag didn't report any -Wshadow-uncaptured-local warnings. Unfortunately, clang didn't report any warnings due to clang bug https://bugs.llvm.org/show_bug.cgi?id=52325: clang -Wshadow-uncaptured-local (and some other -Wshadow*) flags doesn't actually enable these warnings; they're only enabled by the meta flags -Wshadow and -Wshadow-all.
I see now that there are over 500 -Wshadow-uncaptured-local warnings, too many to realistically fix them all, so we should remove -Wshadow-uncaptured-local.
The -Wshadow-field-in-constructor-modified flag is also affected by the clang bug, but I'd like to keep setting the -Wshadow-field-in-constructor-modified flag in case the clang bug is ever fixed. There are no -Wshadow-field-in-constructor-modified warnings in mozilla-central; I fixed the last one in bug 1738400.
Differential Revision: https://phabricator.services.mozilla.com/D132290
We already use the adoptopenjdk on some platforms, this allows us to have a
more predictable Java binary on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D130878
Build and run the Mach virtualenv from a `state_dir` that is
"specific-to-topsrcdir".
As part of this, move `get_state_dir()` to `mach` so that it's usable
before `sys.path` entries are fully set up.
Differential Revision: https://phabricator.services.mozilla.com/D130383
mach will initialize from comm/build/mach_initialize.py if it's present.
See bug 1731160. The initialization function wraps the one in build/mach_initialize.py,
then extends sys.path and loads more mach_commands.py files
Differential Revision: https://phabricator.services.mozilla.com/D131869
Mike Hommey
Marian-Vasile Laza
Jan-Erik Rediger
Nika Layzell
Sandor Molnar
Mitchell Hentges
kriswright
Noemi Erli
Nick Alexander
Chris Peterson
Agi Sferro
Rob Lemley
Christian Holler