We updated win64 builders to rust 1.18 while it was still in
beta to pick up better crash reporting. Bump those builds to
the stable toolchain now that it's released.
MozReview-Commit-ID: 1LlmrDfLfWL
--HG--
extra : rebase_source : 4c14198cf962db26a072cd4b6316edbe870cf5bd
A number of developers find it convenient to build with
--disable-optimize --enable-debug for an improved debugging experience.
We don't currently have a configuration in CI that ensures this
combination of options works, so various changes break builds with this
configuration every so often. We should test such configurations to
ensure they build to provide a smooth experience for developers.
Update official builds for 64-bit Windows to use
1.18.0-beta.4 (0308c9865 2017-05-27). This picks
up a fix to unwinding with panic=abort which gives
us better crash reporting on that platform.
MozReview-Commit-ID: HLZSixr8Sxe
For a long time, we've kind of forced the GCC version used to compile
Firefox on automation to the minimum version we do support, because
using a newer version would pretty much guarantee that builds with older
versions would break.
Ideally, the same would be true of rust, but it's not the case, and sure
enough, building with older versions breaks. The most recent example is
bug 1367734 making rustc 1.17.0 required but leaving configure checking
for version 1.15.1.
There are multiple reasons why we'd want to use newer versions of rust
to build shipping versions of Firefox other than language requirements,
but we should still ensure building with supported versions of rust
doesn't break silently.
Here we add a set of new linux jobs that build opt and debug build with
the baseline of supported toolchains. At the moment, that's GCC 4.9,
rust 1.15.1, and clang 3.9 (for bindgen). That's a copy of the current
toolchains used for normal linux jobs, with rustc downgraded to the
package used after bug 1338311.
Further down the line, we'll be able to bump the versions of GCC, rust
and/or clang for the shipped Firefox builds, while keeping those jobs on
GCC 4.9, rust 1.15.1 and clang 3.9, until we do intentionally want to
bump those versions (as well as the corresponding configure checks).
--HG--
rename : browser/config/tooltool-manifests/linux64/releng.manifest => browser/config/tooltool-manifests/linux64/base-toolchains.manifest
extra : rebase_source : 33f609f44c1e70cf970ec8af328e0408e01ec0d2
As of bug 1342503 being fixed, all of our desktop firefox builds have
webrender compiled in by default. Webrender can therefore be enabled at
runtime either by a pref or environment variable on any desktop firefox
build. The old builds that we originally used to stand up webrender are
no longer needed, as the *only* difference between them and the regular
builds are that they build with the pref turned on instead of turned
off. This doesn't warrant keeping around these extra builds, and this
patch removes them along with all the associated goop that was needed to
configure them.
MozReview-Commit-ID: 5wlOWo11fEk
--HG--
extra : rebase_source : 696afdd2d9fb5f7932d0737a7d71c3aa6af0bd64
One of the Rust crates that is built as part of geckodriver's dependency
chain uses a build script to compile some C code.
Because mozbuild does not yet pass the compiler wrapper down to where
the gcc crate can find it, we need to avoid building on geckodriver when
this is the case.
When compiling the browser for the rooting hazard analysis build (labelled
H on Treeherder), the MOZ_HAZARD environment variable will be set and
available to moz.build descriptions.
MozReview-Commit-ID: GprFKtvXvOE
--HG--
extra : rebase_source : f45aa5d8c86673c8287371efcfa703755c2b2073
This avoids some known hazard from replace-malloc itself, and unhides
--disable-replace-malloc hazards if there are any (and there is one from
bug 1361258), which wouldn't be caught until riding trains
(replace-malloc being only enabled on nightly).
The hazard from bug 1361258 that disappears is this one:
Error: Indirect call malloc_hook_table_t.jemalloc_thread_local_arena_hook
Location: replace_jemalloc_thread_local_arena @memory/replace/replace/ReplaceMalloc.cpp#261
Stack Trace:
jemalloc_thread_local_arena @ memory/build/replace_malloc.c#287
Gecko_SetJemallocThreadLocalArena @ layout/style/ServoBindings.cpp#2062
The new hazard from that bug is:
Error: Variable assignment jemalloc.c:arenas_map
Location: jemalloc_thread_local_arena @memory/mozjemalloc/jemalloc.c#3068
Stack Trace:
Gecko_SetJemallocThreadLocalArena @ layout/style/ServoBindings.cpp#2048
Where arenas_map is a thread-local variable, so there really is no
hazard.
--HG--
extra : rebase_source : bea3d2f862ede8c0b90775b6ec9cebb657b9b455
The old archive was uploaded with internal visibility. This was almost
certainly a mistake.
I downloaded the old archive and produced a new one and re-uploaded it to
tooltool with public visibility. I had to reproduce the archive because
tooltool won't let you promote an existing item to public.
It appears that environment state and possibly differences in the
tar command result in diverging tar archives. For example:
==> clang.orig <==
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/bin/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/include/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/lib/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/libexec/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/man/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-build/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-view/
==> clang.new <==
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/bin/
-rwxr-xr-x gps/gps 18099 2017-02-01 20:15 clang/bin/git-clang-format
-rwxr-xr-x gps/gps 6731340 2017-02-01 20:33 clang/bin/llvm-mc
-rwxr-xr-x gps/gps 2241688 2017-02-01 20:34 clang/bin/obj2yaml
-rwxr-xr-x gps/gps 17105264 2017-02-01 20:33 clang/bin/llvm-c-test
-rwxr-xr-x gps/gps 13153616 2017-02-01 20:33 clang/bin/bugpoint
-rwxr-xr-x gps/gps 49666672 2017-02-01 20:33 clang/bin/clang-3.9
-rwxr-xr-x gps/gps 52901 2017-02-01 20:15 clang/bin/scan-build
-rwxr-xr-x gps/gps 6214036 2017-02-01 20:30 clang/bin/llvm-ar
Content within should be identical. It's just the file ordering and
owner bits that are different. This shouldn't matter.
MozReview-Commit-ID: HOzNXAd7xwq
--HG--
extra : rebase_source : 92650cbd1869b744a5f6a1d3534fb512f85b32d1
Update tooltool manifests for official builds to use repacks
of the upstream rustc 1.17.0 (56124baa9 2017-04-24) stable release.
These repacks include cargo 0.19.0-beta.1 (03efb7fc8 2017-04-23)
to include support for the RUSTC_WRAPPER environment variable
needed for use of sccache with rust code.
MozReview-Commit-ID: L9Nq2iK4GK8
--HG--
extra : rebase_source : 882b201282a0e13ed77ec5876972657eab81a562
Update tooltool manifests to reference rustc 1.16.0 stable repacks
which include cargo 1.19.0 nightly builds from 2017-04-19 which
support the RUSTC_WRAPPER environment override.
We're shipping with an unstable cargo while this feature makes its
way to release because it is necessary for deploying sccache support
for rust language code in our build and test automation.
MozReview-Commit-ID: Iow2894OPq7
--HG--
extra : rebase_source : f1a8e6cab612714f7b73ca8a14d14cabe9f4aef7
The version we update to is the current result from the
macosx64-cctools-port toolchain job.
(gotten with `mach artifact toolchain --from-build macosx64-cctools-port --nounpack`
and uploaded to tooltool)
--HG--
extra : rebase_source : 5d980012de2dfab0556ccb7ed27c434047054523
They are, in fact, the same version already, built from the same version
of clang-static-analysis-linux64.json, but one comes from a now expired
try build, and the other from a build on mozilla-central, that can still
be traced down:
https://tools.taskcluster.net/task-inspector/#Ro1bUCv4Svu2OWuQsOF_hA/0
--HG--
extra : rebase_source : 776314cecb3cba7043a02f4e1f2f4feb4b51731c
Also use the same cctools as cross-mac builds of Firefox.
Do dummy changes to the corresponding build scripts so that the builds
are force triggered (toolchain builds are not triggered automatically
when the tooltool manifest they use changes yet).
--HG--
extra : rebase_source : 699143de819c29c98ca31308ac502f9331123403
sccache doesn't actually support clang-cl currently, so we're just making
our clang-cl builds slower by enabling it. Also, I'm trying to update to
a newer version of sccache and something broke running sccache+clang-cl
entirely so my try builds are busted, so disabling it entirely until
we actually support this configuration seems sensible.
MozReview-Commit-ID: LMkVuBRclCp
--HG--
extra : rebase_source : 76357d16190a6d2b2c5f177874de00ed3e636a76
The mercurial revision of sixgill listed in the manifest doesn't exist,
so I took what looks like corresponds to the last change to the tooltool
manifests, in order to avoid any other difference than GMP linkage.
This was built manually on a one-click-loaner.
--HG--
extra : rebase_source : 5ea830e48a6424a6ded9beab0628d0e562251c47
These mozconfigs are no longer used since we stopped doing universal
builds in bug 1295375.
MozReview-Commit-ID: Izz9q1dRskH
--HG--
extra : rebase_source : a7b6f84d56812f0946c78aa054f116747e798300
Apply a 2-character indent to in-tree tooltool manifests to make
them easier to read, and to make the formatting more consistent
so automating updates is simpler.
Modern editors will maintain json indentation. The only long
lines we have are already over 80 characters, so the extra space
shouldn't create new long lines.
Also update mercurial installer script to generate json with
the same indentation, even though its output is temporary.
Tooltool itself was updated to generate manifests with this
indentation in Bug 1325225.
MozReview-Commit-ID: DKj6nL9OENv
--HG--
extra : rebase_source : fc3f8616ec689d74e06c0db84c2b261825f86453
