This adds an overload of GetInitialHeap that takes an ObjectGroup* instead of a Class* and also takes into account whether the group's shouldPreTenure flag is set. I moved this to JSObject-inl.h too.
I removed the heap parameter in a few places, in particular in NewDenseCopyOnWriteArray which required a bunch of changes elsewhere including the JITs. I left the heap parameter intact for environment objects where we may have reason prefer these objects to be allocated in the tenure heap. It's possible we should just remove all these parameters too and make allocation more uniform.
Differential Revision: https://phabricator.services.mozilla.com/D22324
Firefox, comm-central and bluegriffon don't use `*JSAndPlugin*` methods of
`nsIEditingSession` from script. Let's remove or move to `nsEditingSession`.
Differential Revision: https://phabricator.services.mozilla.com/D22465
--HG--
extra : rebase_source : 256fb4025fe8c6f5a61d5b015af942ff65759c23
I'd like to use the same format for config values, that get evaluated in different contexts, so don't
to mutate the config for that.
Differential Revision: https://phabricator.services.mozilla.com/D22126
--HG--
extra : moz-landing-system : lando
Split into one part for JSScript internal initialization of flags and a
second part for linking the JSFunction and JSScript only after the
script is fully initialized.
Depends on D22322
Differential Revision: https://phabricator.services.mozilla.com/D22323
--HG--
extra : moz-landing-system : lando
When compiling a script with lazy inner functions, we now know the
scopes that those inner functions belong too and need to save this
information on the inner function itself (as enclosingScope). This patch
makes that process more explicit in JSScript initialization so we can
better reason about error / OOM paths.
Depends on D22319
Differential Revision: https://phabricator.services.mozilla.com/D22320
--HG--
extra : moz-landing-system : lando
Use an ExitScope similar to to XDRScript for more consistency.
Depends on D22316
Differential Revision: https://phabricator.services.mozilla.com/D22317
--HG--
extra : moz-landing-system : lando
Compute this flag directly from BytecodeEmitter data structures instead
of needing to access the partially initialized script while setting its
own flags.
Depends on D22313
Differential Revision: https://phabricator.services.mozilla.com/D22315
--HG--
extra : moz-landing-system : lando
This removes the redundant set of TreatAsRunOnce which is instead set by
CompileOptions before we start compiling. The IsModule flag is now set
directly similar to IsForEval.
Differential Revision: https://phabricator.services.mozilla.com/D22313
--HG--
extra : moz-landing-system : lando
Artifact mozconfigs are not necessarily up-to-date wrt changes to the
nightly mozconfigs, and all in all, shouldn't be much different from
them.
It's just better to use the nightly mozconfigs (or beta on beta, etc.)
and make the mozconfigs themselves handle the few things that need to be
different when the USE_ARTIFACT environment is set (which is now
consistently set by taskcluster)
This does have the side effect of turning builds that actually don't
support artifact builds red when using --artifact on try, instead of
having them silently not be artifact builds as currently happens.
Depends on D21314
Differential Revision: https://phabricator.services.mozilla.com/D21315
--HG--
extra : moz-landing-system : lando
The artifact builds that are automatically derived using the artifact
template set the USE_ARTIFACT environment variable from taskcluster.
After the previous change, --artifact builds from try syntax do that
too.
That leaves us with only the artifact-build build not doing it, so for
consistency, do it there. That makes it not necessary to set
USE_ARTIFACT from mozconfig.artifact.automation anymore.
Depends on D22056
Differential Revision: https://phabricator.services.mozilla.com/D21313
--HG--
extra : moz-landing-system : lando
Currently, all tasks of kind builds are indiscriminately altered to use
artifacts, but only few of them actually support that, and the others
won't actually have the expected result when that happens. E.g. ASAN
builds with artifacts enabled end up being non-ASAN builds.
Effectively, this makes the artifact flag ignored for builds that don't
support artifacts. One could argue that those builds shouldn't happen at
all, but it feels a better use time of developer's time to just do the
full build they asked for. E.g. if they asked for ASAN with artifacts,
they still get an ASAN build, rather than an error or silently having
the task not happen after the decision task. This also allows to mix
artifact and non-artifact builds.
Further changes down the road are also modifying the artifact builds
configuration, which would actively turn those builds that don't support
artifact builds red (e.g. ASAN), so something has to be done anyways.
The alternative would be filter those builds out.
Depends on D21312
Differential Revision: https://phabricator.services.mozilla.com/D22056
--HG--
extra : moz-landing-system : lando
While try syntax is approaching its EOL, the fact that using it to do
artifact builds does some things subtly differently from using try
config is not helpful.
Depends on D22055
Differential Revision: https://phabricator.services.mozilla.com/D21312
--HG--
extra : moz-landing-system : lando
Jan Varga
Jon Coppeard
Brian Hackett
Andrea Marchesini
Razvan Maries
Emilio Cobos Álvarez
Makoto Kato
Nicolas B. Pierron
Dão Gottwald
Kai Engert
Andreea Pavel
Masayuki Nakano
Coroiu Cristina
Tom Prince
Dorel Luca
Sean Stangl
Jason Laster
J.C. Jones
Ted Campbell
Mike Hommey