I don't know why clang static-analysis wants noexcept specifiers on
these TypeDef methods, but it's trivially true so I don't see an issue
with it.
Differential Revision: https://phabricator.services.mozilla.com/D108212
clang static-analysis complains if you have a variable that is
not initialized at its definition, even if it's always initialized
before it's first use. I don't think it's worth trying to find
a way to appease this warning at this time.
This commit adds initializers to all instances of Nothing to
remove some of these warnings, as this is a trivial case to
fix.
Differential Revision: https://phabricator.services.mozilla.com/D108210
The autofix algorithm for this rule appears to use the definition parameter
name when there is a mismatch. This seems reasonable to me from glancing at
the results.
Differential Revision: https://phabricator.services.mozilla.com/D108206
clang static-analysis prefers to use range-based for loops whenever
it is possible. Some of the replacements are obvious improvements,
while others are a bit murky. Open to discussion on whether these
all make sense.
Differential Revision: https://phabricator.services.mozilla.com/D108204
It turns out that patch for bug 1698543 was too optimistic and we need the special case barrier for rope flattening for another reason: during flattening rope nodes are transformed before their ancestors. Interior rope nodes are transformed to dependent strings with the base being the root node, and the root transformed into a linear string. Since the root is changed last the GC graph is not safe to traverse until flattening has finished.
This makes the test case pass. I added this test case and the one for the previous bug. I don't think we need to hide these since this change has only been on nightly so far.
If there are futher issues with this then I'm going to back out the barrier changes and think about an alteranative approach.
Differential Revision: https://phabricator.services.mozilla.com/D108979
Following the landing of wasm-via-Ion on arm64 (bug 1678097), some obscure
build configurations now break the build due to incorrect target-selection
ifdeffery. This has been observed to happen for x86_64-linux when the
following are specified together (in a browser build):
ac_add_options --enable-cranelift
ac_add_options --enable-js-shell
In particular, `forceWasmIon` is declared in js.cpp and is guarded by
JS_CODEGEN_ARM64. But there were later some uses of it guarded by
ENABLE_WASM_CRANELIFT. In effect this incorrectly assumes that
JS_CODEGEN_ARM64 and ENABLE_WASM_CRANELIFT are both either defined or
undefined. But that's not correct, (eg) for a build on x86_64-linux that is
configured `--enable-cranelift`.
This patch fixes that by guarding such use points *additionally* with
JS_CODEGEN_ARM64, so as to ensure the sets of configurations that read or
write `forceWasmIon` are a subset of the configurations that declare it.
Differential Revision: https://phabricator.services.mozilla.com/D108934
Disable asm.js-via-Ion on arm64 until such time as that pathway, along with
the associated compiler-option logic, is better tested. asm.js will still be
available on arm64, but will be forced along the JS pathway, with the
associated performance lossage. See also bug 1697560.
Differential Revision: https://phabricator.services.mozilla.com/D108925
We are never supposed to check flags directly, we should always go via the 'Available' functions.
So also here: the flag test tests just the flag; the availability test allows the flag value
to be provided by a privileged-extension check.
Differential Revision: https://phabricator.services.mozilla.com/D108819
Currently we have a special path for performing barriers during rope flattening to take account of the fact that this overwrites the cell header word of ropes temporarily, making these cells untraceable.
The problem is that a rope can already be in the barrier buffer before flattening starts and so we need to check for this when processing the buffer.
The patch reworks use of temporary GC data to set one of the cell header flags when in use. This means we can check for it when processing the barrier buffer. It removes the special case function for barriers, which makes it slightly less efficient as we will now buffer all these ropes before skipping them later on. Hopefully that is not too deterimental to performance.
Differential Revision: https://phabricator.services.mozilla.com/D108664
The build always uses them anyways, but configure tests don't, and some
of them fail as a consequence in some cases (example: when UBsan is
enabled, all AC_LANG_CPLUSPLUS + AC_CHECK_FUNCS tests fail). We also had
similar problems in the past, such as bug 1513605.
By adding the PIC flags to CFLAGS and CXXFLAGS, we ensure old-configure
tests use the flags as well.
While here, we also remove DSO_CFLAGS, which was always empty, and we
stop passing -fPIC to wasm compiles, because it has no effect there.
Differential Revision: https://phabricator.services.mozilla.com/D108560
The build always uses them anyways, but configure tests don't, and some
of them fail as a consequence in some cases (example: when UBsan is
enabled, all AC_LANG_CPLUSPLUS + AC_CHECK_FUNCS tests fail). We also had
similar problems in the past, such as bug 1513605.
By adding the PIC flags to CFLAGS and CXXFLAGS, we ensure old-configure
tests use the flags as well.
While here, we also remove DSO_CFLAGS, which was always empty, and we
stop passing -fPIC to wasm compiles, because it has no effect there.
Differential Revision: https://phabricator.services.mozilla.com/D108560
This changes the default so that extra GC poisoning is off in nightly opt builds unless enabled by an environment variable. This should give us more useful telemetry on nightly performance and make it easier for people trying to benchmark our browser. The poisoning is still enabled in debug builds.
The variable is renamed from JSGC_DISABLE_POISONING to JSGC_EXTRA_POISONING.
Differential Revision: https://phabricator.services.mozilla.com/D108419
The br_on_cast instruction is currently too strict and disallows the passing
along extra values. This commit adds validation for this, adds comments clarifying
the baseline implementation of the function, normalizes argument order for
WasmOpIter, and adds a test.
Differential Revision: https://phabricator.services.mozilla.com/D108505
Toplevel `var` and `function` bindings in strict direct eval are now statically
bound. Direct eval code is also permitted to search enclosing scopes, the same
way lazy functions do. References to variables in enclosing scopes will now
typically use aliased ops.
The test change in class/super-in-nested-eval.js causes the test to continue
testing what it was testing before, despite the scoping changes in this and
subsequent patches.
Depends on D107691
Differential Revision: https://phabricator.services.mozilla.com/D107692
In Phase 1, both Ion and Cranelift are available, and the default is switched
to Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to
select Ion, or make sure javascript.options.wasm_force_ion is true in
about:config. Phase 1 is appropriate for fuzzing, after the patch set lands
in mozilla-central but before Ion is enabled by default. The patch for Phase
1 will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
Differential Revision: https://phabricator.services.mozilla.com/D101867
Every operation that updates the SP or PSP must be sure to maintain the
required SP-vs-PSP invariants. Various addToStackPtr APIs did not do this.
Various other code needs tweaks.
This patch documents the existing invariants, and fills in some missing cases
for them. The invariants are, in summary:
* PSP (x28) is the "primary" stack pointer value. SP is "secondary".
* At all times, the invariant SP <= PSP is maintained.
* There are no memory accesses below SP, ever.
* All stack accesses are based off PSP, not SP.
* All function boundaries (calls and returns), SP == PSP.
In some places, where stack-manipulation code is not SP-vs-PSP agnostic,
it has been made clearer whether we are dealing with SP or PSP.
js/src/jit/arm64/Assembler-arm64.h has acquired a large block comment
which records the current invariants in more detail, plus results of
ongoing investigations.
Differential Revision: https://phabricator.services.mozilla.com/D97772
This enables Ion for ARM64 and adds all missing code generation code
for Wasm, except SIMD.
In one case we use a different strategy on ARM64 than on other
platforms, leading to the introduction of a lowerFor...() function
across all the platforms. Otherwise this patch is restricted to
ARM64.
The code generated here may have optimization opportunities still;
that is by design. This patch is only intended to be complete and
correct, not optimal.
Code here was generally adapted from the corresponding x64 and mips64
(sometimes x86-shared and mips-shared) code.
Differential Revision: https://phabricator.services.mozilla.com/D97478
In Phase 0, both Cranelift and Ion are available on arm64, and Ion is the
default. Use --wasm-force-cranelift or --wasm-compiler=cranelift at the shell
to select Cranelift, or set javascript.options.wasm_force_ion to false in
about:config. Phase 0 is appropriate for developers, before the patch set
lands in mozilla-central and before SIMD is present.
In Phase 1, both compilers are still available, but the default is switched to
Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to select
Ion, or make sure javascript.options.wasm_force_ion is true in about:config.
Phase 1 is appropriate for fuzzing, after the patch set lands in
mozilla-central but before Ion is enabled by default. The patch for Phase 1
will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
In Phase 0 and Phase 1, --wasm-compiler=cranelift and --wasm-compiler=ion are
both accepted, and do the expected thing.
In Phase 2, Cranelift becomes disabled in moz.configure and all the changes in
the present patch are removed again. The patch for Phase 2 will appear on bug
1686626 and will revert Phase 0 and Phase 1, and additionally update
moz.configure.
Differential Revision: https://phabricator.services.mozilla.com/D102420
Use the value from BufferSize::get() without checking that it fits in
uint32_t in cases where this makes sense and is straightforward. In
the cases where it still matters, perform additional checking or
rewrite code so that it doesn't matter.
Remove BufferSize::getWasmUint32(), it is now unused. Indeed
BufferSize could be replaced by size_t now.
As a consequence of these changes, we relabel the memory operations so
that it is clear that they are for 32-bit memories, as they would
otherwise have to take 64-bit arguments and have more complicated
overflow checking on source and destination addresses. So long as
only the memory size needs to be larger than 32 bits it's not
complicated.
Drive-by fix a bug where TableCopy used a failure value from MemCopy;
this has no impact on any code, it's just a typo.
Differential Revision: https://phabricator.services.mozilla.com/D98970
The purpose here is to allow wasm memories to use up to 65534 pages of
memory on 64-bit systems, if the underlying ArrayBuffer /
SharedArrayBuffer supports it. (The remaining two pages remain out of
bounds until we can make the bounds checking limit 64 bits wide, and
some other things.)
As the max value of the heap limit field is 65536, this should unlock
memories above 2GB for all users who do not insist on actually
allocating all 4GB.
The changes here are:
* Parameterize everything properly: Get rid of hardcoded UINT32_MAX
and INT32_MAX and similar where that is possible. Some remain;
comments have been added.
* Add guards for asm.js to remain at heap limit INT32_MAX forever
* Add guard for grow() methods to enforce the limit separately from
arraybuffer code
* Add test cases and test infrastructure
* Clean up some transitional things that are no longer required, now
that the underlying arraybuffer code is stable
Some parameters are turned into function calls now, but may become
constants again later.
Differential Revision: https://phabricator.services.mozilla.com/D96602
MOZ_MUST_USE was replaced with [[nodiscard]] in js/rc in bug 1684092, but some new uses of MOZ_MUST_USE instead of [[nodiscard]] have crept back in.
Depends on D108343
Differential Revision: https://phabricator.services.mozilla.com/D108344
To simplify this code, turns these prefs into unlisted prefs on MIPS
platforms since the JIT support is missing there. The JitOptions will
continue to default them to false on MIPS.
Differential Revision: https://phabricator.services.mozilla.com/D108107
