summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Runtime/PromiseReaction.cpp
AgeCommit message (Collapse)Author
2023-04-30LibJS+LibWeb: Normalize calls to Base::visit_edges in GC objectsMatthew Olsson
2022-12-15LibJS: Convert Heap::allocate{,_without_realm}() to NonnullGCPtrLinus Groh
2022-12-14LibJS: Convert PromiseReaction::create() to NonnullGCPtrLinus Groh
2022-10-02LibJS: Make PromiseCapability GC-allocatedLinus Groh
A struct with three raw pointers to other GC'd types is a pretty big liability, let's just turn this into a Cell itself. This comes with the additional benefit of being able to capture it in a lambda effortlessly, without having to create handles for individual members.
2022-10-02LibJS: Move PromiseCapability into its own cpp/h fileLinus Groh
This is not strictly connected to PromiseReaction in any way. Preparation before doing some actual work on it :^)
2022-08-23LibJS: Remove GlobalObject parameter from native functionsLinus Groh
2022-08-23LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]Linus Groh
2022-08-23LibJS: Replace GlobalObject with VM in Promise AOs [Part 8/19]Linus Groh
2022-08-23LibJS: Remove GlobalObject from VM::throw_completion()Linus Groh
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
2022-08-23LibJS+LibWeb: Replace GlobalObject with Realm in create() functionsLinus Groh
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.
2022-05-03LibJS: Remove implicit wrapping/unwrapping of completion recordsLinus Groh
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
2022-02-20LibJS: Use new NativeFunction::create() in most placesLinus Groh
Resolves one FIXME where we can now pass a realm, and sets the length correctly in a bunch of places that previously didn't. Also reduces the number of "format function name string from arbitrary PropertyKey" implementations, although two more remain present in the AST (used with ECMAScriptFunctionObjects, which is a different beast).
2022-02-08LibJS: Setup host hooks and have promise jobs work out the realmLuke Wilde
This allows the host of LibJS (notably LibWeb in this case) to override certain functions such as HostEnqueuePromiseJob, so it can do it's own thing in certain situations. Notably, LibWeb will override HostEnqueuePromiseJob to put promise jobs on the microtask queue. This also makes promise jobs use AK::Function instead of JS::NativeFunction. This removes the need to go through a JavaScript function and it more closely matches the spec's idea of "abstract closures"
2022-01-25LibJS: Use new construct AO overload where easily applicableTimothy Flynn
2021-11-14LibJS: Annotate Promise implementation with spec commentsLinus Groh
I wanted to do this for a long time. The guts of Promise are pretty complex, and it's easier to understand with the spec right next to it. Also found a couple of issues along the way :^)
2021-10-23LibJS: Convert the NewPromiseCapability AO to ThrowCompletionOrIdan Horowitz
2021-10-23LibJS: Remove vm.construct and it's usagesIdan Horowitz
2021-10-20LibJS: Convert NativeFunction callback to ThrowCompletionOrIdan Horowitz
2021-08-23LibJS: Set the function names for the resolve, reject, and executorTimothy Flynn
These should all have a name with an empty string. Not only does test262 verify this, but it also verifies that (for the executor) the name property is defined after the length property.
2021-08-21LibJS: Fix copy-paste mistake in GetCapabilitiesExecutorTimothy Flynn
2021-07-06LibJS: Add define_direct_property and remove the define_property helperIdan Horowitz
This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-06-17LibJS: Fix .length attributes of various native functionsLinus Groh
Namely the Proxy revocation, Promise resolving, Promise then/catch finally, and Promise GetCapabilitiesExecutor functions. They were all missing an explicit 'Attribute::Configurable' argument and therefore incorrectly used the default attributes (writable, enumerable, configurable).
2021-06-13LibJS: Add ECMA-262 section/title/URL comments almost everywhereLinus Groh
As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-10LibJS: Remove GlobalObject& argument from VM::construct()Andreas Kling
We can just get the global object from the constructor function.
2021-04-22Everywhere: Use linusg@serenityos.org for my copyright headersLinus Groh
2021-04-22Everything: Move to SPDX license identifiers in all files.Brian Gianforcaro
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 *
2021-04-02LibJS: Add initial support for PromisesLinus Groh
Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues