| Age | Commit message (Collapse) | Author |
|---|
|
Intrinsics, i.e. mostly constructor and prototype objects, but also
things like empty and new object shape now live on a new heap-allocated
JS::Intrinsics object, thus completing the long journey of taking all
the magic away from the global object.
This represents the Realm's [[Intrinsics]] slot in the spec and matches
its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of
architecture.
In the majority of cases it should now be possibly to fully allocate a
regular object without the global object existing, and in fact that's
what we do now - the realm is allocated before the global object, and
the intrinsics between both :^)
|
|
|
|
|
|
This is a continuation of the previous five commits.
A first big step into the direction of no longer having to pass a realm
(or currently, a global object) trough layers upon layers of AOs!
Unlike the create() APIs we can safely assume that this is only ever
called when a running execution context and therefore current realm
exists. If not, you can always manually allocate the Error and put it in
a Completion :^)
In the spec, throw exceptions implicitly use the current realm's
intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
|
|
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
|
|
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
|
|
This is a manual but clean revert of all commits from #12595.
Adding a partial implementation of the resizable ArrayBuffer proposal
without implementing all the updates to TypedArray infrastructure that
is also covered by the spec introduced a bunch of crashes, so we
decided to revert it for now until a full implementation is completed.
|
|
This is an editorial change in the ECMA-262 spec, with similar changes
in some proposals.
See:
- https://github.com/tc39/ecma262/commit/7575f74
- https://github.com/tc39/proposal-array-grouping/commit/df899eb
- https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12
- https://github.com/tc39/proposal-shadowrealm/commit/c81f527
|
|
This is a normative change in the ECMA-262 spec. See:
https://github.com/tc39/ecma262/commit/e7979fd
Note that this implements a FIXME in InitializeTypedArrayFromTypedArray,
now that shared array buffers are no longer a concern there. We already
have test coverage for the now-handled case.
|
|
The spec notes that this AO is unused by ECMA-262, but is provided for
ECMAScript hosts. Move the definition to a common location to allow
test-js to also use it.
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
|
|
|
|
Test262 seems to test the changes in the "Resizable ArrayBuffer and
growable SharedArrayBuffer" proposal. Begin implementing this proposal
by accepting the new options object argument to the ArrayBuffer
constructor.
https://tc39.es/proposal-resizablearraybuffer
https://github.com/tc39/test262/blob/main/test/built-ins/ArrayBuffer/options-maxbytelength-diminuitive.js
|
|
|
|
This also allows us to create TypedArrays with an existing buffer thus
clearing up an additional FIXME in TextEncoder.
|
|
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
|
|
|
|
This should be used instead of ArrayBuffer::create() in most places, as
it uses OrdinaryCreateFromConstructor to allow for a custom prototype.
The data block (ByteBuffer) is allocated separately and attached
afterwards, if we didn't fail due to OOM.
|
|
Let's use Base::visit_edges() when calling the base class, to prevent
accidentally skipping over anyone in the inheritance chain.
|
|
...by replacing it with a ctor that takes the buffer instead, and
handling the allocation failure in ArrayBuffer::create(size_t) by
throwing a RangeError as specified by the spec.
|
|
|
|
As required by the specification:
`Set buffer.[[ArrayBufferDetachKey]] to "WebAssembly.Memory".`
|
|
This is required by the specification and will be used for the
$262.detachArrayBuffer method in test262.
|
|
The exception order was incorrect in the old implementation, and it
did not use the Symbol.species constructor as required by the spec.
|
|
This is implemented as a ByteBuffer* in a variant, so its size should
only be increased by an index.
|
|
|
|
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
|
|
Implements the aforementioned native Javascript function, following the
specification's [1] implementation.
[1] https://tc39.es/ecma262/#sec-arraybuffer.prototype.slice
|
|
|
