Bug 1798623: Update time zone data to tzdata2022f (ESR102 backport). r=#platform-i18n-reviewers, a=dmeehan


Backport for ESR102.

Differential Revision: https://phabricator.services.mozilla.com/D161009

Bug 1796901 - Clear realm incremental marking state at the start of GC rather than at the end r=jandem, a=dmeehan

GC can be aborted in several states and zones GCRuntime::finishCollection
doesn't always get called. It's easier to clear this state in a signle place at
the start.

Differential Revision: https://phabricator.services.mozilla.com/D160056

When marking a BaseShape we mark its global, and we read the pointer to that
global from the realm. If a realm doesn't have a live global we can sweep the
realm but there may still be pointers to it in base shapes and these are left
dangling.

This happens when we hit OOM while creating a global during an incremental GC.
The BaseShape survives because it was allocated after the start of the GC. The
global itself is never successfully created and so the realm doesn't have a
live global and is swept. In this case, we trigger UAF when we try to compact
the heap and trace the base shape.

The patch adds an extra case for keeping a realm alive if it was created during
an incremental GC. This matches the way that GC things are not collected if
they are allocated after the start of a GC.

Differential Revision: https://phabricator.services.mozilla.com/D158022

Differential Revision: https://phabricator.services.mozilla.com/D157735

It's pretty confusing that this name is sometimes used for local variables and
sometimes refers to the current mark color.

Depends on D157733

Differential Revision: https://phabricator.services.mozilla.com/D157734

Delayed marking may push more (normal, non-delayed) marking work. We need to do
this before switch mark color from black to gray since we cannot add gray
marking work while there is black marking work on the stack.

Differential Revision: https://phabricator.services.mozilla.com/D157733

Differential Revision: https://phabricator.services.mozilla.com/D157612

Differential Revision: https://phabricator.services.mozilla.com/D156605

Differential Revision: https://phabricator.services.mozilla.com/D152305

Differential Revision: https://phabricator.services.mozilla.com/D152304

Differential Revision: https://phabricator.services.mozilla.com/D155068

Differential Revision: https://phabricator.services.mozilla.com/D152822

We can't exit early if src.IsEmpty() if the stack is non-empty.

Differential Revision: https://phabricator.services.mozilla.com/D152899

The paradigm for DEBUG is that it is defined or not defined, not 1 or 0,
so we have to use ifdef here. Otherwise we get a build error in embedded
SpiderMonkey when DEBUG is not defined.

Differential Revision: https://phabricator.services.mozilla.com/D152556

When installing embedded SpiderMonkey, we need to install the generated
header ProfilingCategoryList.h into /usr/include/mozjs-___/js/ because
that's where the rest of the SpiderMonkey code expects to find it.
It's not automatically installed already, because it's generated.

Thanks to Arai for the suggestion of where to look.

Differential Revision: https://phabricator.services.mozilla.com/D152549

Bug 1774249 - Fallibly generate unique ID for new prototypes in JSObject::setProtoUnchecked r=jandem a=pascalc

Generate unique IDs for objects that are used as prototypes ahead of time, so
we can do it fallibly.

Differential Revision: https://phabricator.services.mozilla.com/D149356

Differential Revision: https://phabricator.services.mozilla.com/D150097

Differential Revision: https://phabricator.services.mozilla.com/D147305

Differential Revision: https://phabricator.services.mozilla.com/D147281

The implementation was incomplete. It is possible to have the same
control data field in the SimdShuffle. The ValueNumberer algorithm
wrongfully merging non-congruent values.

Compare all SimdShuffle fields, including opd, permuteOp, and shuffleOp.

Differential Revision: https://phabricator.services.mozilla.com/D148569

Bug 1770167 - Self-test switch from CLI to evaluate options, to follow the test suite. r=arai, a=test-only

The CLI options seems good while testing manually, or while fuzzing, but seems
to cause issues in CI which are hard to reproduce. None of our test cases are
using the CLI options as of today, and instead they all rely on the evaluate
function provided with a delazification mode.

This patch changes the usage to fit what our test suite is actually using for
testing instead of testing CLI options.

Differential Revision: https://phabricator.services.mozilla.com/D147869

Bug 1770609 - Update private name token position when starting processing a new scope to ensure good diagnostics r=arai

Differential Revision: https://phabricator.services.mozilla.com/D147463

This moves the parameter names and other data to a header file and adds a
command line option --gc-param.

Differential Revision: https://phabricator.services.mozilla.com/D147428

Remove the gating in moz.configure that prevents the arm64 simulator from
being compiled on an arm64 system.

Avoid using the fjcvt instruction when running on arm64 hardware, since
the simulator does not appear to support it while cpu detection does
support it.  (The alternative would be to implement the instruction
on the simulator.)

Differential Revision: https://phabricator.services.mozilla.com/D147199

Differential Revision: https://phabricator.services.mozilla.com/D147453

Differential Revision: https://phabricator.services.mozilla.com/D147427

Bug 1769518 - Support Rooted<Result<V,E>> as long as V and E have GCPolicy<> defined for them. (Use IgnoreGCPolicy for whichever of them does not need tracing.) r=emilio,nbp,jonco

Differential Revision: https://phabricator.services.mozilla.com/D146468

The JS-API for global constructor [1] has a step for throwing
a TypeError when type is v128. We previously would just throw
a TypeError if a default value was provided and type was v128.

Two unused error messages are removed, and a comment for clarity
on the error handling of ToValType is added.

[1] https://webassembly.github.io/spec/js-api/index.html#globals

Differential Revision: https://phabricator.services.mozilla.com/D147179

Differential Revision: https://phabricator.services.mozilla.com/D147276

The comment about running code is no longer relevant after bug 1277278, see
patch part 1 in bug 1277278.

Depends on D144012

Differential Revision: https://phabricator.services.mozilla.com/D144013

The ArgumentsObject for inlined arguments was always allocated through a VM-call,
which made it slower when compared to non-inlined arguments.

Differential Revision: https://phabricator.services.mozilla.com/D144012

This removes the API and skips the tests. The implementation in
mozJSComponentLoader is not removed.

This patch will be backed out after the next merge.

Differential Revision: https://phabricator.services.mozilla.com/D147278

Bug 1767834: Properly support "collation" as an option when creating an Intl.Collator object. r=platform-i18n-reviewers,gregtatum

We didn't set the "collation" property as a Unicode locale extension, so it
was effectively ignored.

Differential Revision: https://phabricator.services.mozilla.com/D145475

These don't block off-thread parsing any more so we should be able to remove
this heuristic.

Differential Revision: https://phabricator.services.mozilla.com/D147096

Something I didn't realise is that remapping a wrapper can make the wrapper
point at the original target again after nuking it. The code assumed that nuked
wrappers stayed dead.

Wrappers to finalization record objects (not registries) are not exposed so I
think we can skip recomputing wrappers to these.

Our assertions were a little over-eager here too. We shouldn't expect to see an
entry in the cross-zone records table for records that have their 'in map' flag
cleard, even if the entry hasn't been removed by sweeping yet.

Differential Revision: https://phabricator.services.mozilla.com/D147090

Differential Revision: https://phabricator.services.mozilla.com/D146347

Move a number of Array-oriented testing functions to lib/wasm.js, as we
keep copying them from file to file, with variations.

The main sticking point here was actually that the simd tests include
a common testing file using an include: directive, but this directive
is processed before the common include: directive that loads wasm.js.

Unfortunately the present patch creates a dependency wherein the simd
common testing file will depend on wasm.js being loaded first.

To fix the dependency order the simd tests were updated to load the
common testing file explicitly, and this load will happen after
wasm.js is loaded.

Differential Revision: https://phabricator.services.mozilla.com/D147053

Differential Revision: https://phabricator.services.mozilla.com/D147161

This simplifies the next patch because we can rename `BaselineFrameReg64` to `FramePointer64`.

Depends on D147159

Differential Revision: https://phabricator.services.mozilla.com/D147160