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
Consolidate Mach virtualenv management to the front of the
Mach process. This obsoletes `./mach create-mach-environment`
and simplifies the `sh` portion of the top-level `./mach` script.
This helps ensure that the Mach virtualenv doesn't become
out-of-sync and simplifies the mental model of the Mach
virtualenv situation.
Differential Revision: https://phabricator.services.mozilla.com/D120401
`--no-virtualenv` was needed for one use case: the
`get_and_diffoscope` task, despite not needing `psutil`, would
run into failures during virtualenv-creation because we used to
unconditionally build the `psutil` package, and `get_and_diffoscope`
didn't have the environment needed for such a build.
Since we no longer build and install `psutil` into every virtualenv,
it's no longer needed for its one usage, which means that it can be
removed.
`--requirements` is replaced by `--virtualenv`, which removes an
ad-hoc pip package installation and embraces the centralized dep
system.
`--no-activate` is now implied by default: a virtualenv is only
created and activated if `--virtualenv` is provided.`
`ipython==7.16.1` was the chosen version because it is the last
one compatible with Python 3.6.
Differential Revision: https://phabricator.services.mozilla.com/D131529
At Mach initialization time, it needs to know if it's not running from
the Mach virtualenv so it can decide to insulate itself from the
external sys.path.
However, the current mechanism of detecting the Mach virtualenv
struggles if the venv is old, and therefore missing its metadata file.
In such a case, it's recognized as "not the Mach venv" rather than "an
out-of-date Mach venv".
As part of this, I'm realizing that simply using the metadata file as a
"virtualenv has finished building" marker is insufficient, because it
will cause similar confusion here. This is solved with a "finalization"
key in in the metadata.
Differential Revision: https://phabricator.services.mozilla.com/D130794
This is needed because `black==21.11b1` requires `click>=7.1.2`
`pathspec<1,>=0.9.0`, and `typing-extensions>=3.10.0.0`.
Differential Revision: https://phabricator.services.mozilla.com/D127163
The revert doesn't have a lot of impact, as it's only for debug info
about enums with a 128-bits integer representation.
Differential Revision: https://phabricator.services.mozilla.com/D132001
It assumes 16-bytes alignment for small allocations on 64-bits, which is
not true for mozjemalloc allocations.
This only addresses the problem with mozilla.org-produced builds. We may
have to figure out something for downstreams.
Differential Revision: https://phabricator.services.mozilla.com/D131883
This is needed because `black==21.11b1` requires `click>=7.1.2`
`pathspec<1,>=0.9.0`, and `typing-extensions>=3.10.0.0`.
Differential Revision: https://phabricator.services.mozilla.com/D127163
Jan-Erik Rediger
Mike Hommey
Marian-Vasile Laza
Sandor Molnar
Nika Layzell
Mitchell Hentges
kriswright
Noemi Erli
Nick Alexander
Chris Peterson
Agi Sferro
Rob Lemley
Christian Holler
Shravan Narayan
Butkovits Atila