Commit graph

10 commits

Author SHA1 Message Date
Linus Groh
194d90dc72 LibJS: Don't coerce this value to object in Promise.prototype.finally() 2021-11-14 15:27:46 +00:00
Linus Groh
53ec432e8d LibJS: Don't coerce this value to object in Promise.resolve() 2021-11-14 15:27:46 +00:00
Linus Groh
a53542e0a3 LibJS: Clear exception after running each queued Promise job
It's not what the spec tells us to do. In fact, the spec tells us the
exact opposite:

    9.5 Jobs and Host Operations to Enqueue Jobs
    https://tc39.es/ecma262/#sec-jobs

    A Job is an Abstract Closure with no parameters that initiates an
    ECMAScript computation when no other ECMAScript computation is
    currently in progress.
    ...
    Their implementations must conform to the following requirements:
    - ...
    - The Abstract Closure must return a normal completion, implementing
      its own handling of errors.

However, this turned out to not be true in all cases. More specifically,
the NewPromiseReactionJob AO returns the completion result of calling a
user-provided function (PromiseCapability's [[Resolve]] / [[Reject]]),
which may be an abrupt completion:

    27.2.2.1 NewPromiseReactionJob ( reaction, argument )
    https://tc39.es/ecma262/#sec-newpromisereactionjob

    1. Let job be a new Job Abstract Closure with no parameters that
       captures reaction and argument and performs the following steps
       when called:
       ...
       h. If handlerResult is an abrupt completion, then
          i. Let status be Call(promiseCapability.[[Reject]],
             undefined, « handlerResult.[[Value]] »).
       i. Else,
          i. Let status be Call(promiseCapability.[[Resolve]],
             undefined, « handlerResult.[[Value]] »).
       j. Return Completion(status).

Interestingly, this case is explicitly handled in the HTML spec's
implementation of jobs as microtasks:

    8.1.5.3.3 HostEnqueuePromiseJob(job, realm)
    https://html.spec.whatwg.org/webappapis.html#hostenqueuepromisejob

    2. Queue a microtask on the surrounding agent's event loop to
       perform the following steps:
       ...
       5. If result is an abrupt completion, then report the exception
          given by result.[[Value]].

This is precisely what all the major engines do - but not only in
browsers; the provided code snippet in the test added in this commit
works just fine in Node.js, for example.

SpiderMonkey:
https://searchfox.org/mozilla-central/rev/25997ce8267ec9e3ea4b727e0973bd9ef02bba79/js/src/builtin/Promise.cpp#6292
https://searchfox.org/mozilla-central/rev/25997ce8267ec9e3ea4b727e0973bd9ef02bba79/js/src/builtin/Promise.cpp#1277
https://searchfox.org/mozilla-central/rev/25997ce8267ec9e3ea4b727e0973bd9ef02bba79/js/src/vm/JSContext.cpp#845

JavaScriptCore:
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/builtins/PromiseOperations.js?rev=273718#L562
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/runtime/JSMicrotask.cpp?rev=273718#L94

V8:
https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/promise-abstract-operations.tq;l=481;drc=a760f03a6e99bf4863d8d21c5f7896a74a0a39ea
https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/builtins-microtask-queue-gen.cc;l=331;drc=65c9257f1777731d6d0669598f6fe6fe65fa61d3

This should probably be fixed in the ECMAScript spec to relax the rule
that Jobs may not return an abrupt completion, just like in the HTML
spec. The important bit is that those are not surfaced to user code in
any way.
2021-11-12 15:35:03 +02:00
Timothy Flynn
76589d6728 LibJS: Change wording of ErrorType::NotA to be independent of context
Currently, we have NotA and NotAn, to be used dependent on whether the
following word begins with a vowel or not. To avoid this, change the
wording on NotA to be independent of this context.
2021-09-12 00:16:39 +02:00
Timothy Flynn
4f186a9a1f LibJS: Implement Promise.race on the Promise constructor 2021-08-23 00:01:46 +01:00
Timothy Flynn
949f294444 LibJS: Implement Promise.allSettled on the Promise constructor 2021-08-23 00:01:46 +01:00
Timothy Flynn
4dffa40a8d LibJS: Implement Promise.any on the Promise constructor 2021-08-23 00:01:46 +01:00
Timothy Flynn
dee3b7b8c9 LibJS: Implement Promise.all on the Promise constructor 2021-08-21 23:08:49 +01:00
Linus Groh
b377777208 LibJS: Add @@toStringTag to Promise.prototype 2021-06-08 19:13:14 +01:00
Linus Groh
f418115f1b LibJS: Add initial support for Promises
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
2021-04-02 10:47:40 +02:00