I don't intend to install ccache in the Debian build images. Hazard
builds are the only builds running on the desktop-build image still
using ccache somehow, and that gains them nothing, since the ccache
directory is not set to a cached directory on taskcluster, meaning
the build always starts with an empty cache. If anything, this currently
makes the build slower.
Eventually, those builds should be able to use sccache, once the
necessary setup moves out of mozconfig.cache.
On Debian, the autoconf binary is autoconf2.13 while it is autoconf-2.13
on Centos.
In make-source-package.sh, we need to run autoconf to generate the
old-configure to include in the package, so try both.
In hazard-analysis.sh, we actually don't need autoconf itself, so just
copy configure.in to configure.
These scripts are included by hazard-analysis.sh. That's their only
reference in repo.
We could probably inline these scripts. But let's start by moving them
out of mozharness since no active mozharness based task is using them.
MozReview-Commit-ID: 13oen42Txmh
I also snuck in some last-minute assertions and minor fixes into this patch:
- don't stop reporting for a callee if we've seen it already (or rather, make the reachable set local to a root rather than global to all roots). This slows down runs with hundreds of hazards, but results in every problematic root being reported, for a more accurate count.
- annotate away some thread assertions
- special-case annotation for bug 1400435 since it's a whole family of hazards
Allow an extra heap write hazard introduced by enabling stylo
in default builds until it can be addressed. See bug 1384625.
MozReview-Commit-ID: 2N3z6FVHa0G
This is a quick work around for not blocking the progress of Bug 1380133.
We should definely investigate the real root cause sooner than later.
MozReview-Commit-ID: 8X1FH6f2GyN
This is a quick work around for not blocking the progress of Bug 1380133.
We should definely investigate the real root cause sooner than later.
MozReview-Commit-ID: 8X1FH6f2GyN
A quick fix for hazard bustage by increase the NUM_ALLOWED_WRITE_HAZARDS
from 3 to 7 is pushed in bug 1348173 comment 37. In this bug, we shall do
the actual fix and restore the NUM_ALLOWED_WRITE_HAZARDS.
The -moz-border-*-colors bindings trigger errors because they're using
outparams (nsStyleBorder) which further manipulate its member (mBorderColors)
which is a double raw pointers. Since we don't have the ability to
whitelist the indirect access to mBorderColors[x] list, we can only add
them to the ignoreContents for now.
We might be able to move these bindings to the whitelist of the above
treatAsSafeArgument function, if we could refactor mBorderColors to use
nsTArray directly.
MozReview-Commit-ID: 2cQz58K2A10
Tasks calling these generally use tooltool and the hazard
manifest to provide toolchains, but the setup job doesn't
they don't use a mozconfig to configure paths, and the analysis
job uses a different TOOLTOOL_DIR.
The build calls configure, which defaults to --enable-rust,
so we need to add the correct rust toolchain path to the
environment like we do for C++.
MozReview-Commit-ID: gFnZ0SK1f7
Historically, a mozinfo for js standalone build has not been necessary,
but with the move towards a) having things work with mach and b)
buildconfig using the MozbuildObject.from_environment in next patch,
mozinfo becomes necessary (it's required for
MozbuildObject.from_environment to find the directory is an objdir).
Interestingly, hazard builds do both a js standalone build and a desktop
Firefox build at the same time, both of which are done with MOZCONFIG
set in the environment... with the Firefox mozconfig. The result of now
writing a mozinfo for js standalone builds is that in that case, they
end up with a reference to the mozconfig, which the build system then
reads, and finds a MOZ_OBJDIR, which then doesn't match the js
standalone build objdir. So for those builds, reset MOZCONFIG.
