In bug 1580003 I missed two calls that still use isLastMultiSelectChange.
This parameter has no effect and can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D104427
The "Arbitrary module namespace identifier names" spec PR allows to use "*" as
a module export name, so we can no longer use that specific string to denote
star-imports/exports. Probably the easiest way to work around this new
restriction is to replace "*" with a nullptr string.
Spec change: https://github.com/tc39/ecma262/pull/2155
Differential Revision: https://phabricator.services.mozilla.com/D101013
The approach to use "*" for namespace imports/exports no longer works with
module export names. As an alternative add separate ImportNamespaceSpec and
ExportNamespaceSpec parse nodes. They're currently still implemented as binary
nodes, but the next part will change this.
Differential Revision: https://phabricator.services.mozilla.com/D101012
Inline `ModuleBuilder::appendExportFromEntry()` in preparation for the next
part. The `computeLineAndColumn()` call can be moved to the top, because
`spec->pn_pos.begin` is equal to `localNameNode->pn_pos.begin` by construction,
cf. `FullParseHandler::newImportSpec()`.
Drive-by changes:
- Use `auto*` in more places.
- Drop `frontend::` which is redundant with `using namespace js::frontend`.
- Remove the `if (exportName)` check in `ModuleBuilder::appendExportEntry()`,
because `exportName` is never a nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D101011
Import declaration parsing was implemented in `Parser` instead of
`GeneralParser`, which required to add access to several other parsing methods
from `GeneralParser` to `Parser`. We can avoid this by simply moving `import`
declaration parsing into `GeneralParser`.
Differential Revision: https://phabricator.services.mozilla.com/D101010
Splits the `namedImportsOrNamespaceImport()` method into `namedImports()` and
`namespaceImport()`. `namedImportsOrNamespaceImport()` didn't contain any shared
code, so it seems better to split it into two separate methods to avoid an
extra nesting level.
Differential Revision: https://phabricator.services.mozilla.com/D101008
The spec change adds a new `ModuleExportName` production to allow exporting/importing
module bindings using string literals. The strings can contain any characters except
unpaired surrogates (i.e. standalone lead or trail surrogates).
`ModuleExportName` can be used in import declarations:
- `import {ModuleExportName as IdentifierName} from ModuleSpecifier`
In export batch declarations:
- `export* as ModuleExportName from ModuleSpecifier`
When exporting local bindings:
- `export {IdentifierName as ModuleExportName}`
And when re-exporting bindings:
- `export {IdentifierName as ModuleExportName} from ModuleSpecifier`
- `export {ModuleExportName as IdentifierName} from ModuleSpecifier`
- `export {ModuleExportName as ModuleExportName} from ModuleSpecifier`
- `export {ModuleExportName} from ModuleSpecifier`
Support for "*" as a ModuleExportName is added in a later part.
Spec change: https://github.com/tc39/ecma262/pull/2154
Differential Revision: https://phabricator.services.mozilla.com/D101000
Performance event entries should only be retrieved by
PerformanceObserver, so it can't be retrieved by using
Performance.GetEntries* APIs.
Differential Revision: https://phabricator.services.mozilla.com/D102036
Atomic fetch operations are effectful, which means they're attached to a resume
point. And because a resume point counts as a use, the "forEffect" optimisation
was never triggered. This is a regression from bug 1146364.
This optimisation is especially useful for atomic operations on BigInts, because
it allows us to omit the allocation of the result BigInt.
`WarpCacheIRTranspiler::emitAtomicsBinaryOp()` pushes `undefined` on the stack
when the "forEffect" optimisation is used, which should be okay because the
result is directly popped from the stack again.
ARM64:
Add the implementation for `LAtomicTypedArrayElementBinopForEffect` which is now
required to be present.
Depends on D104174
Differential Revision: https://phabricator.services.mozilla.com/D104175
Updates CacheIR for AtomicReadModifyWrite operations to support BigInt results.
Similar to part 3, add a temporary `supportBigInt` flag which will later be
removed again.
Depends on D104170
Differential Revision: https://phabricator.services.mozilla.com/D104171
Similar to the previous parts, CacheIR always calls into the VM and only Warp
performs the operation in inline assembly.
TypePolicy.cpp:
- Add `TruncateToInt32OrToBigIntPolicy` similar to the existing `TruncateToInt32Policy`.
- `TruncateToInt32Policy` will be removed at the end of this patch series.
CodeGenerator.cpp:
Add `createBigIntOutOfLine()` so we can call it from "CodeGenerator-x86.cpp".
x86:
The lack of free registers makes it necessary to use the stack more often to
temporarily save some registers.
Depends on D104167
Differential Revision: https://phabricator.services.mozilla.com/D104170
For CacheIR we're using an ABI call, because each platform has specific register
requirements we don't want to handle in CacheIR.
ARM32 and x86:
Reuse the existing WASM functions for `MacroAssembler::atomicStore64()`.
x86-only:
We're running out of registers, so we have to reuse `edx` as an additional temp
register.
ARM64 and x64:
Call `MacroAssembler::store64()` with an explicit memory barrier.
Differential Revision: https://phabricator.services.mozilla.com/D104167
For CacheIR we're using a VM call, because each platform has specific register
requirements we don't want to handle in CacheIR.
ARM32 and x86:
Reuse the existing WASM functions for `MacroAssembler::atomicLoad64()`.
ARM64 and x64:
Call `MacroAssembler::load64()` with an explicit memory barrier.
Depends on D104165
Differential Revision: https://phabricator.services.mozilla.com/D104166
This flag will be removed again at the end of this patch series. The flag
makes it possible to perform piecewise updates to allow BigInt inputs without
breaking the not yet updated functions.
Depends on D104164
Differential Revision: https://phabricator.services.mozilla.com/D104165
Small helper to abbreviate `ScaleFromElemWidth(Scalar::byteSize(type))` to just
`ScaleFromScalarType(type)`. Later patches will also use this new function.
Differential Revision: https://phabricator.services.mozilla.com/D104164
Move common code for converting operands into `ConvertOperand` and for unboxing
operands into `UnboxOperand`. Part 6 will also use `ConvertOperand`.
Differential Revision: https://phabricator.services.mozilla.com/D104162
Now that ScriptSource has no tracing requirements, we can replace the custom
wrapper time with a more gecko-friendly RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D104478
