Bug 247785 - TypeError in parameter destructuring in async function should be a rejected promise
Summary: TypeError in parameter destructuring in async function should be a rejected p...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yijia Huang
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-11-11 00:56 PST by Kanguk Lee
Modified: 2022-11-18 17:55 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kanguk Lee 2022-11-11 00:56:56 PST
// input.js
async function f (...[ [] ]) { } 

f().catch(e => print("caught"));
_____________________

Hello,

Executing the input.js using JSC throws TypeError, but it should print "caught".

Running the input.js with JSC results in:

---
$ jsc input.js
Exception: TypeError: undefined is not an object (evaluating '[ [] ]')
f@input.js:1:22
global code@input.js:3:2
---

while other engines behave like:

---
# V8 (used console.log)
$ node input.js
caught

# GraalJS
$ js input.js
caught
---


WebKit version: 615.1.10
Comment 1 Radar WebKit Bug Importer 2022-11-14 09:44:11 PST
<rdar://problem/102325201>
Comment 2 Yijia Huang 2022-11-16 13:38:32 PST
Pull request: https://github.com/WebKit/WebKit/pull/6561
Comment 3 Ross Kirsling 2022-11-16 22:23:07 PST
Hi Kanguk, thanks for your diligent bug reporting lately.

It seems like you've been reporting these spec conformance issues to each engine individually, but the ideal approach is really to ensure that there is adequate Test262 coverage (https://github.com/tc39/test262), such that engines can easily notice that there's a new failure.

In this particular case, SpiderMonkey is also failing (https://bugzilla.mozilla.org/show_bug.cgi?id=1799288), but having separate bug reports for us and for them means that we're working on a shared goal separately -- in particular, if two engines have misread the spec in the same way, then it's likely that a third will, so it's *crucial* to have a Test262 case ensuring that all engines are understanding the spec correctly.

And once you've ensured that a Test262 case exists, if you're still really excited about encouraging a fix in JSC, you could create a bug which points to that failing Test262 case. :D
Comment 4 EWS 2022-11-18 17:54:59 PST
Committed 256864@main (29265f95211b): <https://commits.webkit.org/256864@main>

Reviewed commits have been landed. Closing PR #6561 and removing active labels.