`asyncFromSyncIteratorObject[ASYNC_FROM_SYNC_ITERATOR_OBJECT_ITERATOR_SLOT]` is
the iterator passed to `CreateAsyncFromSyncIterator()`, but we actually need to
use `asyncFromSyncIteratorObject` for the `iteratorRecord` to correctly unwrap
Promise values. (Same applies for the `next` method.)
Depends on D160479
Differential Revision: https://phabricator.services.mozilla.com/D160480
This ensures `Array.fromAsync` uses the same error message as `Array.from` and
normal iteration (`for-of` and `for-await-of`).
This let's us also remove the `GetIterator` self-hosted function.
Also renamed `asyncIterator` to `iterator`, because the returned iterator isn't
an async iterator.
Depends on D160478
Differential Revision: https://phabricator.services.mozilla.com/D160479
`ValidateShadowRealmObject` didn't correctly handle non-CCW wrappers and was
missing error reporting when `CheckedUnwrapDynamic()` returned `nullptr`. Switch
to `UnwrapAndTypeCheckValue` to fix both issues.
Depends on D160513
Differential Revision: https://phabricator.services.mozilla.com/D160514
Move the `AutoRealm` in `WrappedFunctionCreate` into a separate block to ensure
we're back in the original realm when we call `CopyNameAndLength`. Without this
change an error thrown `CopyNameAndLength` can escape the wrong realm to resp.
from the ShadowRealm.
Also add some `cx->check()` calls to ensure arguments are in the correct compartment
in `GetWrappedValue` and `WrappedFunctionCreate`. And add `cx->compartment()->wrap()`
in some places which we're using the wrong compartment.
Differential Revision: https://phabricator.services.mozilla.com/D160513
The previous code assumed that the "name" property is always a string, but
user-code can redefine it to any value, which could easily lead to an exploit.
Furthermore the spec requires that the computed string matches the `NativeFunction`
production, so even if we only append the "name" when it's a string value, we'd
first have to parse the string as an identifier to determine if the string has to
be escaped or not. This is non-trivial, so instead follow the `toString` output
of bound functions and return an unnamed function source code string.
Depends on D160510
Differential Revision: https://phabricator.services.mozilla.com/D160511
Avoid to call the resolve hook for the "name" property and avoid unnecessary
atomisation of the "name" string: `IdToFunctionName` returns its input when
no function prefix is passed and the input is a JSAtom. And `JS_StringToId` only
atomises the input string. Both operations are unnecessary here.
Also avoid single letter, upper case variable names for consistency with the
rest of the SpiderMonkey code base.
Depends on D160506
Differential Revision: https://phabricator.services.mozilla.com/D160507
Prefer the internal API for consistency with the rest of SpiderMonkey. This
also avoids some extra overhead, for example we don't have to store the call
arguments first in `RootedVector<Valu>` and then copy them into `InvokeArgs`.
Directly using `InvokeArgs` also fixes some cross-compartment assertions in the
current code, because it skips the compartment checks from `JS::Call` when it
directly calls `js::Call`. Part 10 will fix this code to use the correct
compartment for all values.
Depends on D160505
Differential Revision: https://phabricator.services.mozilla.com/D160506
- `CallArgs::operator[]` returns a rooted value, so it's not necessary to
re-root it.
- It's not necessary to root a value when it's stored in `CallArgs::rval()`.
Depends on D160504
Differential Revision: https://phabricator.services.mozilla.com/D160505
Clang-format writes each entry on a separate line when a trailing comma is
present. This produces nicer output in some cases.
Differential Revision: https://phabricator.services.mozilla.com/D160504
This patch doesn't change behavior; it's just expanding an abbreviated typename.
Without this patch, my local static-analysis build fails with the following
error for mozStorageStatementJSHelper.h (which has a class that implements
nsIXPCScriptable and is outside of SpiderMonkey):
"error: The fully qualified types are preferred over the shorthand typedefs for
JS::Handle/JS::Rooted types outside SpiderMonkey."
The error message points to the NS_DECL_NSIXPCSCRIPTABLE macro, and
specifically to a usage of this typename inside of that macro. This patch's
type-expansion seems to appease this static analysis rule.
Before this patch, the type here was `JS::MutableHandleIdVector` which is a
typedef for `MutableHandle<StackGCVector<JS::PropertyKey>>` as defined here:
https://searchfox.org/mozilla-central/rev/fe5c9c39a879b07d5b629257f63d825c3c8cd0ed/js/public/TypeDecls.h#98
After this patch, the type here is `JS::MutableHandleVector<JS::PropertyKey>`
(which I took from the static analysis error message's suggestion). That
expands to the same full-qualified type, since `MutableHandleVector<T>` is an
alias for `MutableHandle<StackGCVector<T>>` as defined here:
https://searchfox.org/mozilla-central/rev/fe5c9c39a879b07d5b629257f63d825c3c8cd0ed/js/public/TypeDecls.h#128
Differential Revision: https://phabricator.services.mozilla.com/D160690
DONTBUILD because this is just whitespace cleanup.
I found the files to fix up here using this command:
grep -r ' ' * 2>/dev/null | grep -v "other-licenses" | grep "idl:"
I replaced the tab characters with however many spaces seemed consistent with
the indentation in the surrounding code (and did some minor space-indentation
cleanup in contextual lines to preserve alignment, in a few cases).
Differential Revision: https://phabricator.services.mozilla.com/D160577
Currently we initialize the mark stack to a different size depending on whether
or not incremental GC is enable. However, after the first GC we always shrink
it to the initial size when it is disabled.
This bug shows that there's no point having separate sizes so this patch
removes the option and uses a single size regardless.
Differential Revision: https://phabricator.services.mozilla.com/D160528
Currently we have a GC parameter that allows setting a maximum mark stack
capacity. This is only ever used by test code, not in the browser. This
requires extra unnecessary work in release builds if we move to a different
stack representation as we won't be able to fold the comparison into the
current capacity check as we do now.
The patch makes this feature condtional on JS_GC_ZEAL.
Depends on D160526
Differential Revision: https://phabricator.services.mozilla.com/D160527
Currently the way mark colors work for delayed marking doesn't align with
normal marking for gray marking of GC things that can only be marked black
(e.g. strings).
Normal marking keeps these on the gray mark stack, but when it comes to mark
them they are marked black. Currently OOM during marking pushes arenas
containing such GC things onto the delayed black marking list. This means that
gray marking can cause delayed black marking. This is surprising and an
unnecessarily additional complication.
The patch makes this work the same as normal marking. OOM during gray marking
always pushes arenas onto the gray marking list; arenas on the gray marking
list are marked black if they are a GC thing kind that cannot be marked gray.
Depends on D160524
Differential Revision: https://phabricator.services.mozilla.com/D160525
Parallel marking will use one GCMarker per thread. The testing mark queue is
really a per-runtime data structure, so this patch moves it to the GCRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D160524
Currently we initialize the mark stack to a different size depending on whether
or not incremental GC is enable. However, after the first GC we always shrink
it to the initial size when it is disabled.
This bug shows that there's no point having separate sizes so this patch
removes the option and uses a single size regardless.
Differential Revision: https://phabricator.services.mozilla.com/D160528
Currently we have a GC parameter that allows setting a maximum mark stack
capacity. This is only ever used by test code, not in the browser. This
requires extra unnecessary work in release builds if we move to a different
stack representation as we won't be able to fold the comparison into the
current capacity check as we do now.
The patch makes this feature condtional on JS_GC_ZEAL.
Depends on D160526
Differential Revision: https://phabricator.services.mozilla.com/D160527
Currently the way mark colors work for delayed marking doesn't align with
normal marking for gray marking of GC things that can only be marked black
(e.g. strings).
Normal marking keeps these on the gray mark stack, but when it comes to mark
them they are marked black. Currently OOM during marking pushes arenas
containing such GC things onto the delayed black marking list. This means that
gray marking can cause delayed black marking. This is surprising and an
unnecessarily additional complication.
The patch makes this work the same as normal marking. OOM during gray marking
always pushes arenas onto the gray marking list; arenas on the gray marking
list are marked black if they are a GC thing kind that cannot be marked gray.
Depends on D160524
Differential Revision: https://phabricator.services.mozilla.com/D160525
Parallel marking will use one GCMarker per thread. The testing mark queue is
really a per-runtime data structure, so this patch moves it to the GCRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D160524
Currently we initialize the mark stack to a different size depending on whether
or not incremental GC is enable. However, after the first GC we always shrink
it to the initial size when it is disabled.
This bug shows that there's no point having separate sizes so this patch
removes the option and uses a single size regardless.
Depends on D160527
Differential Revision: https://phabricator.services.mozilla.com/D160528
Currently we have a GC parameter that allows setting a maximum mark stack
capacity. This is only ever used by test code, not in the browser. This
requires extra unnecessary work in release builds if we move to a different
stack representation as we won't be able to fold the comparison into the
current capacity check as we do now.
The patch makes this feature condtional on JS_GC_ZEAL.
Depends on D160526
Differential Revision: https://phabricator.services.mozilla.com/D160527
Currently the way mark colors work for delayed marking doesn't align with
normal marking for gray marking of GC things that can only be marked black
(e.g. strings).
Normal marking keeps these on the gray mark stack, but when it comes to mark
them they are marked black. Currently OOM during marking pushes arenas
containing such GC things onto the delayed black marking list. This means that
gray marking can cause delayed black marking. This is surprising and an
unnecessarily additional complication.
The patch makes this work the same as normal marking. OOM during gray marking
always pushes arenas onto the gray marking list; arenas on the gray marking
list are marked black if they are a GC thing kind that cannot be marked gray.
Depends on D160524
Differential Revision: https://phabricator.services.mozilla.com/D160525
Parallel marking will use one GCMarker per thread. The testing mark queue is
really a per-runtime data structure, so this patch moves it to the GCRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D160524
I saw something like a 5% improvement to the Elm, React, and React-Redux
subtests of speedometer with this, with maybe a 1% overall Speedometer
improvement, although the confidence is lower.
Differential Revision: https://phabricator.services.mozilla.com/D158983
We noticed this while looking at the CacheIR generated for an add-slot stub.
The depth threshold of 4 was picked by browsing around on the web and dumping the observed depth. 4 is enough to cover 95%+ of the cases I saw.
There are a couple of other places where we use LoadProto: the no-teleporting case in `GeneratePrototypeGuards`, and `ShapeGuardPrototypeChainForCrossCompartmentHolder`. They didn't show up in my experiments, so I left them alone for now.
Differential Revision: https://phabricator.services.mozilla.com/D158037
This commit switches the representation of PackedType (and therefore ValType/FieldType)
to use a *TypeDef instead of type index.
There are several changes here:
1. PackedTypeCode is always 64-bits now to pack the pointer. This penalizes 32-bit
platforms, but we likely don't care about them enough to try to optimize this.
2. RefType::TypeIndex is RefType::TypeRef
3. RefType::typeIndex() is RefType::typeDef()
4. TypeContext now stores a map from *TypeDef to original type index for printing errors
5. Decoding a RefType now stores a *TypeDef instead of type index
6. We now just transfer the SharedTypeContext from ModuleEnvironment to Metadata instead
of copying definitions. This is needed for sharing the indexOf map.
7. We now manually serialize/deserialize TypeContext
8. TypeContext now stores SharedTypeDef in vector instead of TypeDef, this is needed so
that *TypeDef is not invalidated across resizing the vector (asm.js does this)
9. The initialization of TypeContext is refactored to keep the indexOf map in-sync
with adding new types (asm.js needs this)
10. We now manually serialize/deserialize PackedTypeCode using a new SerializedTypeCode
11. Serialization now needs a TypeContext in order to get the index of type definitions
12. Deserialization now constructs a TypeContext, and uses that when deserializing
ValType/RefType/FieldType
Differential Revision: https://phabricator.services.mozilla.com/D157387
PackedType will store a pointer to *TypeDef in a later commit, making it
non-cacheable POD. We therefore need to specially handle it in serialization.
This commit starts preparing for that.
Differential Revision: https://phabricator.services.mozilla.com/D157386
TypeIdDesc describes how to load the 'type id' for any type. Right now the
'type id' is an immediate integer for small function types, a *FuncType for
larger function types, and *RttValue for everything else.
The immediate integer case is an optimization for signature checks in
call_indirect. We can simplify our code by adding an 'immediateType_'
field to `FuncType` which stores an alternate representation of the
function type (if any) that can be used with call_indirect. Then
`TypeIdDesc`/`TypeDefWithId` are not needed during instantiation
anymore and we can just pass `TypeDefVector` from compilation to
runtime.
As a drive-by fix, some code for setting up the global data are of
Instance was simplified to allocate whole contiguous areas, instead
of looping, in some cases.
Some uses of TypeIdDesc still remain after this commit, but they are
only in codegen for figuring out how to emit signature checks. The
class is renamed and simplified to CallIndirectId to represent this.
Differential Revision: https://phabricator.services.mozilla.com/D157385
PackedType calls isValid() frequently before calling some accessor on
PackedTypeCode which then also calls isValid(). PT and PTC have slightly
different isValid() methods, with the only difference that PT will ensure
that the typeCode is valid for ValType or FieldType, and that PTC will
ensure that the typeCode has been initialized.
Because we check PT.isValid() when constructing a PT, any check that
PTC has been initialized should be equivalent to PT.isValid().
Differential Revision: https://phabricator.services.mozilla.com/D157384
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
The existing optimisation didn't always work, for example when dead resume point
operands were added, represented by MConstant(JS_OPTIMIZED_OUT). Change the
optimisation to allow uses, as long as all uses are within the current block.
Because we also check that all instructions within the block are dead-if-unused,
all uses must also be dead-if-unused.
Differential Revision: https://phabricator.services.mozilla.com/D158403
Currently the table population is done separately from marking the entry which
means we check the key color twice, potentially getting different results if
another thread is marking at the same time. This could result in us not adding
ephemeron table entries when necessary.
The patch consolidates these two paths.
Depends on D159677
Differential Revision: https://phabricator.services.mozilla.com/D159678
We don't need to trace weakmap values that are in the nursery because these
will be kept alive in minor GC by the store buffer entry pushed by HeapPtr.
Differential Revision: https://phabricator.services.mozilla.com/D159677
The allocation metadata builder hook means that we can GC during allocation and
observe this object in a partially initialized state.
Differential Revision: https://phabricator.services.mozilla.com/D159673
This removes the barrier tracer and marks GC things immediately when barriers
fire. This restores the original behaviour before the separate barrier tracer
was added.
Differential Revision: https://phabricator.services.mozilla.com/D159492
This commit switches the representation of PackedType (and therefore ValType/FieldType)
to use a *TypeDef instead of type index.
There are several changes here:
1. PackedTypeCode is always 64-bits now to pack the pointer. This penalizes 32-bit
platforms, but we likely don't care about them enough to try to optimize this.
2. RefType::TypeIndex is RefType::TypeRef
3. RefType::typeIndex() is RefType::typeDef()
4. TypeContext now stores a map from *TypeDef to original type index for printing errors
5. Decoding a RefType now stores a *TypeDef instead of type index
6. We now just transfer the SharedTypeContext from ModuleEnvironment to Metadata instead
of copying definitions. This is needed for sharing the indexOf map.
7. We now manually serialize/deserialize TypeContext
8. TypeContext now stores SharedTypeDef in vector instead of TypeDef, this is needed so
that *TypeDef is not invalidated across resizing the vector (asm.js does this)
9. The initialization of TypeContext is refactored to keep the indexOf map in-sync
with adding new types (asm.js needs this)
10. We now manually serialize/deserialize PackedTypeCode using a new SerializedTypeCode
11. Serialization now needs a TypeContext in order to get the index of type definitions
12. Deserialization now constructs a TypeContext, and uses that when deserializing
ValType/RefType/FieldType
Differential Revision: https://phabricator.services.mozilla.com/D157387
PackedType will store a pointer to *TypeDef in a later commit, making it
non-cacheable POD. We therefore need to specially handle it in serialization.
This commit starts preparing for that.
Differential Revision: https://phabricator.services.mozilla.com/D157386
TypeIdDesc describes how to load the 'type id' for any type. Right now the
'type id' is an immediate integer for small function types, a *FuncType for
larger function types, and *RttValue for everything else.
The immediate integer case is an optimization for signature checks in
call_indirect. We can simplify our code by adding an 'immediateType_'
field to `FuncType` which stores an alternate representation of the
function type (if any) that can be used with call_indirect. Then
`TypeIdDesc`/`TypeDefWithId` are not needed during instantiation
anymore and we can just pass `TypeDefVector` from compilation to
runtime.
As a drive-by fix, some code for setting up the global data are of
Instance was simplified to allocate whole contiguous areas, instead
of looping, in some cases.
Some uses of TypeIdDesc still remain after this commit, but they are
only in codegen for figuring out how to emit signature checks. The
class is renamed and simplified to CallIndirectId to represent this.
Differential Revision: https://phabricator.services.mozilla.com/D157385
PackedType calls isValid() frequently before calling some accessor on
PackedTypeCode which then also calls isValid(). PT and PTC have slightly
different isValid() methods, with the only difference that PT will ensure
that the typeCode is valid for ValType or FieldType, and that PTC will
ensure that the typeCode has been initialized.
Because we check PT.isValid() when constructing a PT, any check that
PTC has been initialized should be equivalent to PT.isValid().
Differential Revision: https://phabricator.services.mozilla.com/D157384
While we're here, make the setup more consistent across host/target
c/c++, and remove the C compiler warning flags from the C linker flags,
where they are irrelevant.
Differential Revision: https://phabricator.services.mozilla.com/D159358
The ability to run arbitrary JS can cause various problems. This replaces the callback
with a different mechanism to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D159513
Some profiling of tcampbell's React benchmark [1] shows 6.1 million calls to
js::frontend::GeneralTokenStreamChars<..>::getFullAsciiCodePoint, using 110.57
million instructions (x86_64). That comes out to only 18 insns per call,
which suggests the method is a good candidate for inlining, but it isn't
inlined.
Merely parking an inline annotation on it doesn't help much, because it gets
inlined into js::frontend::TokenStreamSpecific<..>::getCodePoint, but that
isn't inlined into *its* caller(s), so the 6.1 million calls move to
::getCodePoint instead.
This patch requests inlining for both ::getFullAsciiCodePoint and
::getCodePoint and adds some MOZ_NEVER_INLINE annotations to ensure that cold
paths *don't* get inlined into these two, to reduce code bloat and avoid
excessive register pressure.
IsAscii functions in mfbt/TextUtils.h have been marked inline as a precaution;
this probably isn't necessary.
Run time with config [2] is reduced from 0.390 seconds to 0.379 seconds
(2.8% speedup, best of 50 runs), and from 0.402 to 0.396 seconds
(median of 50 runs).
Instruction count falls from 3511.8 million to 3395.8 million, and the number
of data accesses from 1563.7 million to 1487.4 million -- a 4.8% reduction
that is probably caused by avoidance of save/restore sequences in the inlined
fns.
[1] https://github.com/mozilla-spidermonkey/matrix-react-bench
[2] Fedora 35, x86_64, Intel Core i5 1135G7 at 4 ish GHz
configure: --disable-debug --enable-optimize="-g -O2"
run: --no-threads
Differential Revision: https://phabricator.services.mozilla.com/D159500
I saw something like a 5% improvement to the Elm, React, and React-Redux
subtests of speedometer with this, with maybe a 1% overall Speedometer
improvement, although the confidence is lower.
Differential Revision: https://phabricator.services.mozilla.com/D158983
Calls in original asm.js source code that result in function calls at the wasm level
require preservation of the original JS line number. This metadata is through a
callSiteLineNums vector which needs to be iterated through exactly in sync between
the compiler and bytecode generator. We have this logic in ion, but for some reason
it also exists in baseline, even though baseline is never used (and won't be) for
asm.js code.
This commit removes logic related to line numbers from baseline, simplifying the
logic. Previously, we needed to consume the potential line number at the beginning
of the instruction, then propagate it to wherever the function call would be. Now
we can just read the bytecode offset of the current instruction whenever we need
it.
Differential Revision: https://phabricator.services.mozilla.com/D159201
This commit fixes actionable clang-tidy warnings in js/src/wasm.
There are some slight functional changes here, but nothing major.
Most of the issues are:
* Mismatched decl/def arg names
* Redundant if (cond) return true; else return false;
* Unsigned to signed is implementation defined
* Unnused definitions
* Typedef instead of using
* Uninitialized definitions
There are still a bunch of clang-tidy warnings, but they're
cases where our style is not matched with clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D159194
An exception handling tag `(tag $name)` will nearly always have at
least one param for communicating the pointer to the thrown exception.
We should increase the inline storage in this vector so that we
don't have to allocate in this case. We do this already with the
ValTypeVector used in this class.
Differential Revision: https://phabricator.services.mozilla.com/D159191
Calls in original asm.js source code that result in function calls at the wasm level
require preservation of the original JS line number. This metadata is through a
callSiteLineNums vector which needs to be iterated through exactly in sync between
the compiler and bytecode generator. We have this logic in ion, but for some reason
it also exists in baseline, even though baseline is never used (and won't be) for
asm.js code.
This commit removes logic related to line numbers from baseline, simplifying the
logic. Previously, we needed to consume the potential line number at the beginning
of the instruction, then propagate it to wherever the function call would be. Now
we can just read the bytecode offset of the current instruction whenever we need
it.
Differential Revision: https://phabricator.services.mozilla.com/D159201
This commit fixes actionable clang-tidy warnings in js/src/wasm.
There are some slight functional changes here, but nothing major.
Most of the issues are:
* Mismatched decl/def arg names
* Redundant if (cond) return true; else return false;
* Unsigned to signed is implementation defined
* Unnused definitions
* Typedef instead of using
* Uninitialized definitions
There are still a bunch of clang-tidy warnings, but they're
cases where our style is not matched with clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D159194
An exception handling tag `(tag $name)` will nearly always have at
least one param for communicating the pointer to the thrown exception.
We should increase the inline storage in this vector so that we
don't have to allocate in this case. We do this already with the
ValTypeVector used in this class.
Differential Revision: https://phabricator.services.mozilla.com/D159191
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
This adds a new native structure to hold the cyclic module record fields. This
removes a bunch of marshalling to and from Values.
Differential Revision: https://phabricator.services.mozilla.com/D159485
Annoyingly this definition is needed in builtin/ModuleObject.h which is included
via vm/Scope.h, but frontend/Stencil.h already includes vm/Scope.h. This moves
it to vm/SharedStencil.h.
Differential Revision: https://phabricator.services.mozilla.com/D159484
The only remaining user of this function uses it as an awkward way to get the
debug name of a timer callback function. We should just provide it with a
straightforward way to do that instead.
Differential Revision: https://phabricator.services.mozilla.com/D159335
It shouldn't actually keep us out of Baseline anymore, and `eval` should be
enough to prevent any heavy optimization.
I tried replacing the `eval()` with `Cu.exportFunction` to create native stack
frames in a definitely-not-JITtable way, but the frames were too small, and
the stub JS function calls started failing with stack overflow errors at the
same time as the "heavy" native calls.
That also happened to uncover a fairly obvious bug in the existing test, in
that we can't actually report a failed assertion when we're out of stack
space, and just wind up throwing another stack overflow or allocation error
instead.
Differential Revision: https://phabricator.services.mozilla.com/D159225
They haven't been scriptable in years, so there's no need for them to go
through XPIDL or for the methods to be virtual.
Differential Revision: https://phabricator.services.mozilla.com/D158081
Some more of these tests could probably be removed completely, but they still
leave some vestigial opaque COW tests that might still be worse something,
even though they should be completely redundant.
Differential Revision: https://phabricator.services.mozilla.com/D158997
They haven't been scriptable in years, so there's no need for them to go
through XPIDL or for the methods to be virtual.
Differential Revision: https://phabricator.services.mozilla.com/D158081
We noticed this while looking at the CacheIR generated for an add-slot stub.
The depth threshold of 4 was picked by browsing around on the web and dumping the observed depth. 4 is enough to cover 95%+ of the cases I saw.
There are a couple of other places where we use LoadProto: the no-teleporting case in `GeneratePrototypeGuards`, and `ShapeGuardPrototypeChainForCrossCompartmentHolder`. They didn't show up in my experiments, so I left them alone for now.
Differential Revision: https://phabricator.services.mozilla.com/D158037
I don't know whether this is the problem, but if we try and cancel a request
that has already been cancelled it would produce this crash.
Differential Revision: https://phabricator.services.mozilla.com/D159167
The dom::MaybeWrapValue() method was calling `isObject()` rather than
`hasObjectPayload()`, causing an assertion failure when passed a value
representing an ExtendedPrimitive (record or tuple). This was causing a crash
when evaluating a record or tuple literal either in the navigation bar or
the developer console. In addition, js::ToBooleanSlow() was missing a case
for ExtendedPrimitives, which would also cause an assertion failure in the
same scenario.
For documentation, I also added explicit assertions to dom::...Wrap...()
methods defined in BindingUtils.h that aren't expected to support
ExtendedPrimitives.
I also added placeholders for pretty-printing records and tuples in the
console (fully rendering these values is left for Bug 1772157).
Depends on D156494
Differential Revision: https://phabricator.services.mozilla.com/D148062
The --delazification-mode set a parsing mode which is incompatible with code
coverage. This patch works around this limitation by changing `-e` and adding an
equivalent of `-f`, named `-p` to parse everything eagerly until the skip
condition can be evaluated.
This patch also updates the test suite harness to prefix the `prologue.js` file
with `-p` to avoid crashes with the delazification-mode and JS code coverage.
Differential Revision: https://phabricator.services.mozilla.com/D158851
browser_exception_leak.js is intentionally creating a leak, so maybe the unused
doc is intentional.
browser_import_mapped_jsm.js is deliberately testing the behavior of Cu.import,
so ignore the failure there.
Differential Revision: https://phabricator.services.mozilla.com/D158507
One place was missing an explicit return.
The eslint-disable-next-line is needed because the analysis doesn't
seem to understand the non-static string.
The return was split into a separate line because that made eslint
complain that we needed to be consistent about returns, though
the return type of defineModuleGetter is undefined.
Finally, I updated the ChromeUtils.import() calls so they weren't using
the deprecated argument.
Differential Revision: https://phabricator.services.mozilla.com/D158506
This used to be needed to improve the debugging information, but isn't any more.
I fixed up the whitespace at the same time to match what the automated formatter
would have done in the next patch, to reduce gratuitous churn.
Differential Revision: https://phabricator.services.mozilla.com/D158970
I removed test_bug596580.xhtml because it is testing JS versioning for
the subscript loader, which is long gone.
This adds XPCNativeWrapper as a valid global object. It is already allowed
for the other two kinds of mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D158504
Also change .eslintignore to cover the other directories.
This also fixes the indentation the automatic fixer messed up in a few XHTML files.
Differential Revision: https://phabricator.services.mozilla.com/D158503
The eslint autofixer makes URLs that appear in strings in JS into https://
URLs. However, it does not change any URLs in the HTML part of the tests, which
caused some tests to fail. To try to ensure that the autofixer didn't break
tests in any way that doesn't show up as a failure, I did a light audit of the
tests. Specifically, I looked at files in js/xpconnect/tests/chrome/ containing
the string "example." in a URL string in more than one place. I switched these
URLs over to https://, both in JS and HTML.
I left alone test_secureContexts.html, which uses an http:// URL in HTML, but
is clearly trying to test http://.
I did a similar check for mochi.test but there weren't any tests that used it
more than once.
The tests that originally were broken by the autofix were:
* test_evalInWindow.xhtml
* test_expandosharing.xhtml
* test_wrappers.xhtml
* test_xrayic.xhtml
My audit didn't find any other instances that looked like they might fail. I
did fix a few other places, but I think in those cases the HTML and JS URLs were
cross origin anyways so it shouldn't really matter if one is https:// and the
other is http://.
I also changed single quotes to double quotes for the URLs I changed, because
the autofix is going to do that anyways.
Differential Revision: https://phabricator.services.mozilla.com/D158502
If there's something I'm missing here that's totally fine, I just keep making
this change locally and reverting it and it would be convenient to just leave
it.
Differential Revision: https://phabricator.services.mozilla.com/D158038
André Bargull
Stanca Serban
Daniel Holbert
Jon Coppeard
Iulian Moraru
Jan de Mooij
Henri Sivonen
Cristian Tuns
Csoregi Natalia
Christian Holler
Doug Thayer
Matthew Gaudet
Iain Ireland
Ryan Hunt
Mark Banner
Mike Hommey
Tooru Fujisawa
Robert Longson
Tom Ritter
Marian-Vasile Laza
Julian Seward
Sandor Molnar
Steve Fink
Andrew Halberstadt
Kris Maglione
Dan Minor
Yury Delendik
Kris Maglione
Tim Chevalier
Nicolas B. Pierron
Alexandre Poirot
Andrew McCreight
Zhao Jiazhong