An earlier part changed the `digit` function to be `const`, so we can now make
these two functions `const`, too.
Differential Revision: https://phabricator.services.mozilla.com/D54765
--HG--
extra : moz-landing-system : lando
We never define `HAVE_INT128_SUPPORT`, so the uint128 code path is never
enabled. Change the test to use `__SIZEOF_INT128__` to enable it on
applicable platforms.
Differential Revision: https://phabricator.services.mozilla.com/D54762
--HG--
extra : moz-landing-system : lando
Similar to the previous part, also add a fast-path when multiplying two Bigints
which fit into uint64_t. When the result also fits into uint64_t, this approach
avoids allocating unused malloc memory.
Differential Revision: https://phabricator.services.mozilla.com/D54761
--HG--
extra : moz-landing-system : lando
Add a fast path for uint64 BigInts to `BigInt::absoluteAdd`. This fast path
gives a substantial speed-up, because addition for uint64 BigInts no longer
needs allocate malloc memory when the result also fits into uint64_t.
Differential Revision: https://phabricator.services.mozilla.com/D54760
--HG--
extra : moz-landing-system : lando
Adds `fitsInUint64` to check if a BigInt fits into uint64_t and `uint64FromNonZero`
to extract an uint64_t value from a non-zero BigInt. Boths function are inline
because the next patches will use them in fast-paths.
Differential Revision: https://phabricator.services.mozilla.com/D54759
--HG--
extra : moz-landing-system : lando
Resolves the TODO in `destructivelyTrimHighZeroDigits` and additionally removes
`trimHighZeroDigits`, because it is no longer used. This change is especially
beneficial for functions which are most of the time over-estimating the result
digit length, like for example `BigInt::absoluteAdd`.
Differential Revision: https://phabricator.services.mozilla.com/D54758
--HG--
extra : moz-landing-system : lando
This allows to use these functions without pulling in the complete `jsnum.h` header.
Differential Revision: https://phabricator.services.mozilla.com/D54757
--HG--
rename : js/src/jsnum.h => js/src/util/CheckedArithmetic.h
extra : moz-landing-system : lando
This change passes through the "inner singleton" status of a particular
object literal to the group-assignment logic for JSOP_NEWOBJECT by
instead using a variant opcode, JSOP_NEWOBJECT_WITHGROUP. "Inner
singleton" status is meant to emulate old behavior (prior to ObjLiteral)
in which the frontend built an entire tree of objects/arrays with a
top-level singleton. In the old world, these objects were allocated by
ParseNode::getConstantValue() in the frontend and built by
ObjectGroup::newPlainObject, which looked up an object group by property
names. In the new world, the default NEWOBJECT logic uses a separate
test for whether an allocation site should have a singleton group, and
even after we carefully emulate the old group behavior in the frontend,
the new-object allocation itself will decide to allocate singleton
groups. In the particular regression case motivating this change, these
singleton groups break the TI information for a singleton array (typeset
for all elems no longer has a single group) and as a result, a simple
property access can no longer be inlined. This patch matches the old
behavior and allows the inlining to occur.
Differential Revision: https://phabricator.services.mozilla.com/D54609
--HG--
extra : moz-landing-system : lando
This patch extends the "inner singleton" hack to array element object
literals in the parser. With the new ObjLiteral system, we are
attempting to emulate the old (sometimes incidental) behavior of the
parser's literal object allocation as closely as possible, to avoid
regressions (such as this bug). The "inner singleton" status indicates
that an object would have been allocated as part of a tree objects, with
a singleton at the top, in the old world. In this case, we do something
slightly different with the group setup. The second half of this patch
will extend the inner-singleton bit back through to object allocation
during execution.
Differential Revision: https://phabricator.services.mozilla.com/D54236
--HG--
extra : moz-landing-system : lando
On ubuntu1804 prefers-reduced-motion is reduce so the animations are
being skipped even when we're trying to test them. Force them to run
when running the tests.
Differential Revision: https://phabricator.services.mozilla.com/D55331
--HG--
extra : moz-landing-system : lando
The testcase doesn't have a fragmentainer at all so we should
never set Incomplete status in this case. I added an assertion
that would have caught this. I also made the baseline methods
deal with a null inner frame for good measure.
Differential Revision: https://phabricator.services.mozilla.com/D55389
--HG--
extra : moz-landing-system : lando
This was added for XUL fennec, which was dropped at the time of Firefox 7.
But we're still reading this pref and env var and system info data, so let's
stop doing that (also because 'cpucount' is unlikely to be 1 on modern
desktop machines, we're dropping arbitrary user pref sets for geckoview,
and I don't think it's even possible to set an env var for app execution
on android as a user - certainly not easy).
Depends on D55265
Differential Revision: https://phabricator.services.mozilla.com/D55266
--HG--
extra : moz-landing-system : lando
None of these uses actually need this header. Mostly they need the definitions in GC-inl.h.
Differential Revision: https://phabricator.services.mozilla.com/D55437
--HG--
extra : moz-landing-system : lando
Certain tests load data: URIs, blob: URIs, or otherwise do unusual things
that mean we need to disable the restriction for them.
Differential Revision: https://phabricator.services.mozilla.com/D46501
--HG--
extra : moz-landing-system : lando
While we're here, we also extend the collection period for evalUsage, as it is taking longer to deploy than expected.
Differential Revision: https://phabricator.services.mozilla.com/D53233
--HG--
extra : moz-landing-system : lando
As long as we do not validate incoming messages against the
Chrome DevTools JSON schema, all incoming commands would be
executed. To prevent clients from changing internal data by
calling internal commands (prefixed with "_"), deny their
execution.
Differential Revision: https://phabricator.services.mozilla.com/D55411
--HG--
extra : moz-landing-system : lando
Instead of setting MOZ_QUIET to hide the DOMWINDOW and DOCSHELL log messages, you
now must set a regular logging module to enable them. They are automatically enabled
on tests that rely on these messages are leak checking.
That module is DocShellAndDOMWindowLeak:3
One disadvantage of this change is that you cannot set MOZ_QUIET to hide these
messages when running those tests (primarily browser-chrome).
Differential Revision: https://phabricator.services.mozilla.com/D52413
--HG--
extra : moz-landing-system : lando
André Bargull
Chris Fallin
Noemi Erli
jeffin143
Matthew Gaudet
Sylvestre Ledru
Cosmin Sabou
Mark Striemer
Ciure Andrei
Mats Palmgren
Magnus Melin
Ricky Stewart
Gijs Kruitbosch
emcminn
Alexis Beingessner
Jon Coppeard
Ryan Hunt
Chris H-C
Daisuke Akatsuka
Tom Ritter
Henrik Skupin