Instead of relying on environment variables, pass these in as parameters.
MozReview-Commit-ID: An58Bu2kd1g
--HG--
extra : rebase_source : 9c7b6beb13b676a3376a897f2c8143cc042b8276
I think I copied this from source_test.py, but didn't need it. This patch switches to `optionally_keyed_by` and `resolve_keyed_by`. This also fixes a bug where our next mozilla-beta Fennec beta would have used the dev beetmover pool instead of the production pool.
MozReview-Commit-ID: IdLNmFzieMi
--HG--
extra : rebase_source : a0a37dfd4120597dda198aa5aa1fee59c1026835
In bug 1412690, Dustin noted that the scopes and routes don't belong at the worker level.
To deal with the release indexes, we now have a new `index_builder`. We also add the default
release bbb scope in `build_buildbot_bridge_payload`.
We can and should still move the product info to attributes. I left that for another patch.
MozReview-Commit-ID: 4ZqvnY577S7
--HG--
extra : rebase_source : c894de404f992878764ad434c6f750a8dfee7614
This patch enables building of geckodriver in CI on Linux i686.
MozReview-Commit-ID: GkdHDJrzh2X
--HG--
extra : rebase_source : 2093fcecb9227852295377fe546b1ebe97d6459d
The changesets in bug 1412932 changed the semantics for MOZ_PGO.
Before, it was effectively being set as an environment variable
by client.mk all the time. Afterwards - specifically after
2013c8dd1824 - the variable is set in mozconfigs via ac_add_options,
which means it is only exposed to configure, not the environment.
Investigation by dmajor revealed that -WX (warnings as errors) was
added to a js/src file's compiler invocation after the PGO code
refactor. (PGO and warnings as errors have a strange interaction
- bug 437002 - and should be disabled there.) Strangely, addition
of -WX was only present on Dev Edition PGO builds.
The reason for this is likely mozharness. Mozharness will export
the MOZ_PGO=1 environment variable for build configurations that
it knows are PGO. It appears to do this for all PGO build
configurations except Dev Edition. Since make and moz.configure
inherit environment variables, mozharness was basically papering
over the intended behavior change in 2013c8dd1824.
This commit fixes the problem by marking MOZ_PGO as a JS option
in moz.configure. This means `ac_add_options MOZ_PGO=1` (the new
convention for enabling PGO) will set MOZ_PGO for SpiderMonkey's
moz.configure.
Of course, MOZ_PGO=1 in an environment variable still works. And
mozharness's setting of this variable has the intended effect.
Eventually, I'd like to clean up the mozharness code so it is less
PGO aware and enables PGO via ac_add_options. But that's for another
day.
MozReview-Commit-ID: 1KYPJARI6SJ
--HG--
extra : amend_source : 5291cead9f1c1af9ed2a1f608af770bc8e4958c5
Currently, huge allocations are completely independent from arenas. But
in order to ensure that e.g. moz_arena_realloc can't reallocate huge
allocations from another arena, we need to track which arena was
responsible for the huge allocation. We do that in the corresponding
extent_node_t.
Both functions do essentially the same thing, one having more validation
than the other. We can use a template with a boolean parameter to avoid
the duplication.
Furthermore, we're soon going to require, in some cases, more
information than just the size of the allocation, so we wrap their
result in a helper class that gives information about an active
allocation.
These low level docs are getting out of date and causing confusion. Further,
they are of limited value at this stage anyway.
MozReview-Commit-ID: FSoNniNZjtj
--HG--
extra : rebase_source : fa5e02a771adcae9b0e53bd18c4eb10ebb5315ef
We already remove all change hints down the tree when finding a reframe hint
using ClearServoRestyleFromSubtree in ServoRestyleManager, so this is useless.
MozReview-Commit-ID: 1twx7iPt79x
Source-Repo: https://github.com/servo/servo
Source-Revision: 20ccde9a75e52f3dc7adccf0136f5753deb41158
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4e8d88923fef766a3d9eeca267356ef6962809c6
