The WebAssembly Specification, branch [1] (see also, more generally,
comments in [2]), contains a new test, limits.js, to check whether the
generally agreed embedding limits (numbers of functions, imports, etc) are
observed. This bug is to import the test and fix any resulting breakage
detected with it.
[1] https://github.com/WebAssembly/spec/tree/embedding_limits
[2] https://github.com/WebAssembly/spec/issues/607
* js/src/wasm/WasmBinaryConstants.h:
- Added MaxTableMaximumLength as a counterpart to MaxTableInitialLength.
- Split the constant group into two parts: spec-required, and those
pertaining only to our own implementation.
* js/src/wasm/WasmJS.cpp WasmTableObject::construct():
- Update GetLimits call with correct max size bound
* js/src/wasm/WasmValidate.cpp DecodeTableLimits():
- Implement missing check for a Table's maximum size.
* js/src/jit-test/tests/wasm/import-export.js:
js/src/jit-test/tests/wasm/spec/jsapi.js:
- Update Table maximum size tests. All tests trying to make a Table
with more than 10,000,000 entries now throw instead of succeeding.
* js/src/jit-test/tests/wasm/spec/harness/wasm-module-builder.js:
- Import minimal updates and bug fixes from [1], needed to make the
new tests work.
* js/src/jit-test/tests/wasm/spec/limits.js
- New file. Derived from [1], with comments added to each test to show
SM's compliance situation, and with two tests disabled.
--HG--
extra : rebase_source : a1f1ec730ecae22f2aa0f510c15ebc934489a1b3
This allows us to lazily import global properties using
Cu.importGlobalProperties. Aside from making it easier to avoid lazily
importing these properties, it also defines them all in the shared JSM global
so that we don't risk re-creating them in Sandboxes or frameloader globals.
MozReview-Commit-ID: GV6shguUlIG
--HG--
extra : rebase_source : 6b9269f3b33fe085c5ed63ee16e5b4ce9e5343a4
We should only observe for update errors while we are expecting
a successful update.
MozReview-Commit-ID: 3grGhmxqhIX
--HG--
extra : rebase_source : d099b83560ac5ec15b18fb69177368a645b63952
It turns out sometimes (in the LTO+CFI case at least) Assertions.h
will not be present in the opt build, presumably because it was optimized
out.
MozReview-Commit-ID: GB3GIoSdIUK
mach android-emulator currently supports 6 different avds; I am struggling to maintain
that many configurations. I don't see a lot of value in keeping both 6.0 and 7.0,
and Android 6.0 is not as popular as 7.0. Let's remove 6.0, encouraging 7.0 as an
alternative; same for x86-6.0 -> x86-7.0.
1. Updated hgrepo to work with mozilla-beta, mozilla-esr60 and project branches (just in case)
2. Presquashed commits, so we only submit one.
3. Replaced 'which' with 'command -v' to avoid future shellcheck issues.
Differential Revision: https://phabricator.services.mozilla.com/D1582
This adds 'CorruptionCanaryForStatics', which as the name implies is suitable
for use in objects that are statically declared. It has a trivial destructor
which allows us to avoid the need for static constructors.
--HG--
extra : amend_source : 27f8eff9ead21fde9f5f5d17f16c322d2c995a27
This changes two config options:
pytest_classes = PyTest # only classes that start with 'PyTest' will be considered tests (previously this was Test)
xfail_strict = true # tests marked as xfail will cause pytest to return non-zero if they unexpectedly pass
MozReview-Commit-ID: DCWoDFbe6Mk
--HG--
extra : rebase_source : 9aa806e035d62d51bb338708396851c40f55ee00
When the Windows OS shuts down, we use a synchronous shutdown mechanism,
this exercises session save and restore in a unique way.
MozReview-Commit-ID: 6sCa3E2wmLY
--HG--
extra : rebase_source : 05014c26faa932165b03f922a63ec9576462bc67