This does the following:
- It introduces a controlling ifdef ENABLE_WASM_REFTYPES that enables
exactly those features that are in the reftypes proposal, excluding
those in the gc proposal. Any remaining features (namely, ref.eq,
(ref T) types, struct types) are still under ENABLE_WASM_GC control.
ENABLE_WASM_GC requires ENABLE_WASM_REFTYPES and this is checked.
- It introduces a new TestingFunctions predicate, wasmReftypesEnabled,
that distinguishes reftype-proposal support from gc-proposal
support. We keep wasmGcEnabled to test for gc-proposal support.
- It segregates test cases so that gc-proposal relevant tests are in
their own files, and tests relevant to the reftypes-proposal are now
guarded by wasmReftypesEnabled.
- It renames the predicate HasGcSupport() as HasReftypesSupport(),
since that is what the predicate tests for.
- It has a drive-by fix for the DEBUG-only function wasm::Classify()
to properly put ref.null and ref.is_null under ifdef control.
Reftypes will soon be enabled unconditionally in Nightly (once we can
trace pointers from Ion frames) while gc-types will remain conditional
until Ion supports all the new instructions for struct types. Therefore:
- The command line switch and about:config option are still called
--wasm-gc and j.o.wasm_gc, respectively, which is fine since they will
fairly soon control only gc-proposal features.
- Internal names still use "Gc" rather than "Reftypes", eg,
HasGcTypes, wasmGc_, and so on. This is most appropriate since it
reduces the scope of the patch and these names will pertain mainly
to the gc feature in the future.
--HG--
extra : rebase_source : 51cf3bfe67da594e89195472e4ce1ccfa36c146d
Generalize the testing of GC availability so that it more accurately
reflects whether GC support is actually available, this is a
complicated predicate at present.
(This was motivated by an attempt to generalize the testing
directives, but that generalization does not land yet because it has
some obscure effects that need to be addressed first.)
The generalization sets us up for splitting apart the code and test
cases for the "reftypes" and "gctypes" proposals in a subsequent
patch.
--HG--
extra : rebase_source : 109b6c53206f5f51a34beb9e568ca0183211eb85
extra : intermediate-source : 7f67226aa4e4c6c1c640b6e3439e47a5c34b3f11
extra : source : 33e686de2b00f6a6f1151b113d112e0c2bd66c86
Some unusual keyboard layout may map a function key only with some
modifiers. For example, Hatchak keyboard layout maps Tab key to
"Digit3" key and Backspace key to Level3 Shift+"Digit3" key. So,
when Level3 Shift is active, the modifier state of the "Digit3" key
event shouldn't be ignored because computed keyCode value becomes
DOM_VK_TAB (9) rather than DOM_VK_BACK_SPACE (8).
This patch makes KeymapWrapper::ComputeDOMKeyCode() compute keyCode
value of non-printable key event with its modifier state first. If
it cannot map to a DOM keyCode value, then, it keeps ignoring the
modifier state for backward compatibility and making web apps be able
to identify the key as far as possible.
This mouse click seems superfluous, as window.focus() is called immediately after.
In addition, this click is somehow causing a page up scroll, as it's clicking
a slider frame. This causes the test to fail with scroll anchoring enabled,
for some reason. Removing this click seems to be the easiest solution, as it
doesn't seem intentional.
Differential Revision: https://phabricator.services.mozilla.com/D16276
--HG--
extra : rebase_source : 6e41d587e54d083b0930173d12db1fc180ae70fa
extra : histedit_source : a604e48df440974b7554b6ee8be01641abd92a64
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
This disables NSS_ALLOW_SSLKEYLOGFILE in beta in release in order to avoid shutdown hangs until the NSS project has time to fix the root cause of the issue.
--HG--
extra : rebase_source : 51c84d4841308d283f993a7fda576031d7c4f449
The command-line parameter used by nsEmbedFunctions.cpp is turned into
an nsIFile, and then said nsIFile is never used. Its last use was
deleted in bug 1407693, where we reworked how extra annotations were
done.
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
This patch also removes the last vestiges of the old architecture dropdown
structure, and removes a use of GetBinaryTypeW because it doesn't seem to
return a useful result for any ARM ISA.
Differential Revision: https://phabricator.services.mozilla.com/D14811
--HG--
extra : moz-landing-system : lando
Android mercilessly kills the parent in low memory situations, and we
don't want that to trigger a crash when the child is abruptly
disconnected.
Differential Revision: https://phabricator.services.mozilla.com/D16234
--HG--
extra : moz-landing-system : lando
None of the values tested against OS_TEST are actually possible per
split_triplet in build/moz.configure/init.configure, so the code is
dead in practice.
Differential Revision: https://phabricator.services.mozilla.com/D16161
--HG--
extra : moz-landing-system : lando
LLVM_PROFDATA needs the toolchain search dir, per bug 1515579.
Also, most of the options actually don't do anything useful with
artifact builds. In fact, the only one that artifact builds would need
is MOZ_PGO. So we move to options back to toolchain.configure, somewhere
late enough ; except MOZ_PGO, that we move to the top-level
moz.configure (because we don't need a separate file for one option).
Differential Revision: https://phabricator.services.mozilla.com/D16152
--HG--
extra : moz-landing-system : lando
Handle mp4parse-rust providing cbcs data in the track metadata. Explicitly check
the crypto scheme we get in the metadata and error if we encounter something
outside of cenc and cbcs -- catch unexpected data early.
Differential Revision: https://phabricator.services.mozilla.com/D15878
--HG--
extra : moz-landing-system : lando
