Bug 1726619 - Replace MOZ_LOW_PARALLELISM_BUILD with automated heuristic parallelism based on memory usage, and use for hazard builds r=firefox-build-system-reviewers,glandium

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

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

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

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

This was written by taking the text from here and deleting bits:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Running_Automated_JavaScript_Tests

(Since I initially wrote this patch, that page was removed.)

Notes:

`./mach jstests -h` prints a short mach-specific help message, instead of the full output of `jstests.py -h`. We should probably fix that somehow, because requiring `./mach jstests -- -h` is silly.

The MDN version says "The jstests test suite also includes some tests from web-platform-tests. By default, these are only run when no tests paths are specified; this can be overridden by the --wpt=enabled flag.", but I wasn't sure if that would still be true after the Great Test Realignment, so I left it out.

I've never used `jstestbrowser` before, so I left the content mostly unchanged.

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

This fixes a crash in our test harness, see
https://github.com/koush/AndroidAsync/issues/685.

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

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

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

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

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

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

Note that we don't appear to support 32-bit on mac so it'd be redundant to check for it.

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

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

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

Bug 1715980 - Fix the calendar keyword in Calendar::GetBcp47Type docs; r=platform-i18n-reviewers,dminor DONTBUILD

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

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

Bug 1726416 - Update testcase for Arabic subtending marks (from bug 1599841) now that harfbuzz handles the number-directionality issue internally. r=emilio

We can no longer use direction overrides to create the test vs reference renderings here,
because of how harfbuzz now handles the numeral directionality internally. So it's difficult
to come up with a testcase that verifies the exact rendering of the subtending mark + digit(s)
combinations.

What we can do, though, is verify that a single digit combines with the subtending mark
without affecting its overall width; and that a double-digit number *does* increase the
width. These two conditions are unlikely to both hold unless the rendering is behaving
correctly.

(FWIW, Chrome Canary passes these new test versions, as it also uses a recent harfbuzz;
Safari currently fails, as Core Text doesn't support the subtending marks in the same
way, if at all.)

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

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

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

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

Bug 1729519 - Correct amount of places.sqlite-wal read and writes to cover correct amounts after bug 1727783. r=mak

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

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

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

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

Details in https://bugzilla.mozilla.org/show_bug.cgi?id=1721897#c5

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

Bug 1729867 part 5 - Use same argument order for NewObject and NewObjectWithGivenTaggedProto. r=jonco

Depends on D125045

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

Bug 1729867 part 4 - Remove ObjectFlags argument from NewObject and NewObjectWithGivenTaggedProto. r=jonco

Depends on D125044

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

Depends on D125043

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

Depends on D125042

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

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

Bug 1729689 - Do not require nsITimerCallback implementations to implement nsINamed on release or beta, as runnables don't have names there, r=smaug.

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

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

Bug 1729726 - fix issue on windows where symlink doesn't work. r=perftest-reviewers,AlexandruIonescu

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

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

As discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1719747#c6,
In Part 1, the ownership of the Span in PartsVector is maintained by
ICU. This method adds a callback so js::intl::ListFormat could copy the
content of the Span to Spidermonkey, and mozilla::intl::ListFormat could
use ScopedICUObject to release the string owned by ICU earlier.

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

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

Move implementations to mozilla::intl::ListFormat

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

This is needed for WASI, which has a weird configuration not previously tested.

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

Currently IONFLAGS=codegen doesn't show the assembler offset on any target,
AFAIK. On arm64, at least, reasoning about code offsets merely by looking at
the log output is unreliable, because it is impossible to spot "holes"
(multiple 4-byte insn slots) in the output, and also it is impossible to see
where there has been a transition to a new assembler instance.

This patch fixes it in the obvious way, by printing the offset as 6 hex
digits. Before:

[Codegen] [3] f8408780        ldr     x0, [x28], #8
[Codegen] [3] f85c02e9        ldur    x9, [x23, #-64]

After:

[Codegen] [3] 00b280 f8408780        ldr     x0, [x28], #8
[Codegen] [3] 00b284 f85c02e9        ldur    x9, [x23, #-64]

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