This patch fixues two `gn gen` failures when building CaR with our
toolchain fetched SDK on CI mac workers. First, BUILD.gn has an action
that only works for remote build execution (RBE, which we don't use).
But GN still validates it and rejects our SDK path. Here a patch is
applied with a new guard to catch upstream changes
Second, chromium's c++ modles require modulemap files that are not in
our SDK but we can skip that using use_clang_modules=false. These
modules are a compilation optimization only, so the resulting binary is
still the same.
Old stubs for Bug 1990712 are also removed as they are no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D305765
This patch uses a newer visual studio toolchain (Bug 1999680) for
building CaR. Previously with vs2022 a separate one was maintained for
CaR as there was a mismatch of SDK versions used by chromium and
firefox. With this patch, CaR would be ahead of the eventual upgrade so
we can take advantage of this and avoid build errors associated to
minimum SDK version bumps.
Differential Revision: https://phabricator.services.mozilla.com/D291470
code_cache_generator requires libxcb.so.1 at build time for WebUI code
cache generation but it wasn't in the Docker image. Adding this fixes
this while keeping Linux chromium builds consistent with all other
platforms we currently run.
Also the autoninja retry is removed as it was an attempt to mask a real
failure (Bug 2021140) but didn't end up being helpful.
Root cause of intermittent nature of this is still unclear.
Differential Revision: https://phabricator.services.mozilla.com/D291026
Replaces the mozharness-based openh264-plugin kind, build script, and
platform configs with a shell script-based build that follows the more
typical conventions used by other toolchain builds.
The OpenH264 version is declared once as an attribute on the fetch task
and propagated to downstream tasks via a new transform. Artifacts are now
named openh264-v{version}-{platform}.zip accordingly. A new
openh264-symbol-upload kind uploads the crash symbols produced by each
build to the symbol server.
Treeherder symbols are grouped as OpenH264(B Bs Sym) for build, signing,
and symbol upload respectively.
Differential Revision: https://phabricator.services.mozilla.com/D286418
We don't want to lint test files (yet), they are a big source of noisy
output.
We don't want a unified build, as it duplicates the number of entires
potentially selected (each file maps to it s solo invocation, and its
unified one). Plus because clang-tidy ignores headers, the unified
output is actually filtered out by clang-tidy.
Finally, the batch size of a run_clang_tidy should not depend on the
cpu count, which is already handled by run_clang_tidy. Create large
enough batch to take advantage of parallelism while not hitting CLI
limitations, which was the original purpose (see Bug 1605879).
Differential Revision: https://phabricator.services.mozilla.com/D287945
Further down this stack I'm adding a new Rust tool that lives in the tree and is built by a toolchain task. Running the tests in the toolchain task is not strictly the ideal, but I'm not aware of any solution we have for running tests in a downstream task. (An alternative might be to add a separate task that does the build and runs the tests, but that seems even less ideal.)
Differential Revision: https://phabricator.services.mozilla.com/D287757
We don't want to lint test files (yet), they are a big source of noisy
output.
We don't want a unified build, as it duplicates the number of entires
potentially selected (each file maps to it s solo invocation, and its
unified one). Plus because clang-tidy ignores headers, the unified
output is actually filtered out by clang-tidy.
Finally, the batch size of a run_clang_tidy should not depend on the
cpu count, which is already handled by run_clang_tidy. Create large
enough batch to take advantage of parallelism while not hitting CLI
limitations, which was the original purpose (see Bug 1605879).
Differential Revision: https://phabricator.services.mozilla.com/D287945
Remove p7zip-full and redundant 7zip from Docker images, drop the fallback
binary names from moz.configure, and update win/run.sh to use the fetched
7zz toolchain binary.
Differential Revision: https://phabricator.services.mozilla.com/D288116
`code_cache_generator` sometimes isn't built yet when `ninja` tries to
run it. Build it first explicitly and retry the main build since `ninja`
can pick up where it left off. This incremental building could
potentially fix future similar intermittents as well.
Differential Revision: https://phabricator.services.mozilla.com/D286159
Context: This patch avoids having to manually update the Firefox
Profiler toolchain revision after a Profiler format update, which when
out-of-date, causes symbolication to fail due to a version mismatch
between the Gecko Profiler format version mentioned in-tree
(mozglue/baseprofiler/public/BaseAndGeckoProfilerDetail.h) and the
version supported by symbolicator-cli. Automatically and always using
the latest production commit (expected to be stable) fixes this.
Following Firefox Profiler PR #5746
(https://github.com/firefox-devtools/profiler/pull/5746) and #5747
(https://github.com/firefox-devtools/profiler/pull/5747),
symbolicator-cli no longer outputs WASM modules.
Differential Revision: https://phabricator.services.mozilla.com/D284906
A pgo-extended-corpus CI toolchain task is added that is used during PGO
instrumentation runs. It currently just contains the JetStream3 benchmark,
but could contain other things in the future.
The profilerserver.py now takes a `--extended-corpus` optional flag which
should point at a pgo-extended-corpus artifact. The `pgo/index.html` page
now takes a `?extendedCorpus=true` flag which indicates the corpus should
be used. The android script is different and is not updated yet.
The MOZ_PGO=1 configure option is extended with an additional
MOZ_PGO_EXTENDED_CORPUS=1 option which opts-into the extended-corpus. It
should be provided already through the fetches directory or automatically
downloaded through `bootstrap_toolchain`.
Differential Revision: https://phabricator.services.mozilla.com/D256645
KS