…a rejected promise

https://bugs.webkit.org/show_bug.cgi?id=247785
rdar://102325201

Reviewed by Yusuke Suzuki.

Rest parameter should be caught in async function. So, running this
JavaScript program should print "caught".
```
async function f(...[[]]) { }
f().catch(e => print("caught"));
```

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

GraalJS
```
$ js input.js
caught
```

https://tc39.es/ecma262/#sec-async-function-definitions
...
AsyncFunctionDeclaration[Yield, Await, Default] :
    async [no LineTerminator here] function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }
    [+Default] async [no LineTerminator here] function ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }

AsyncFunctionExpression :
    async [no LineTerminator here] function BindingIdentifier[~Yield, +Await]opt ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }
...

According to the spec, it indicates `FormalParameters` is used for Async
Function, where `FormalParameters` can be converted to `FunctionRestParameter`.

https://tc39.es/ecma262/#sec-parameter-lists
...
FormalParameters[Yield, Await] :
    [empty]
    FunctionRestParameter[?Yield, ?Await]
    FormalParameterList[?Yield, ?Await]
    FormalParameterList[?Yield, ?Await] ,
    FormalParameterList[?Yield, ?Await] , FunctionRestParameter[?Yield, ?Await]
...

And based on RS: EvaluateAsyncFunctionBody, it will invoke the promise.reject
callback function with abrupt value ([[value]] of non-normal completion record).

https://tc39.es/ecma262/#sec-runtime-semantics-evaluateasyncfunctionbody
...
2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)).
3. If declResult is an abrupt completion, then
    a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »).
...

In that case, any non-normal results of evaluating rest parameters should be
caught and passed to the reject callback function.

To resolve this problem, we should allow the emitted RestParameterNode be wrapped
by the catch handler for promise. However, we should remove `m_restParameter` and
emit rest parameter byte code in `initializeDefaultParameterValuesAndSetupFunctionScopeStack`
if we can prove that change has no side effect. In that case, we can only use one
exception handler.

Current fix is to add another exception handler. And move the handler byte codes to
the bottom of code block in order to make other byte codes as much compact as possible.

Input:
```
async function f(arg0, ...[[]]) { }
f();
```

Dumped Byte Codes:
```
...

bb#2
Predecessors: [ WebKit#1 ]
[  20] mov                dst:loc9, src:<JSValue()>(const0)
...

bb#3
Predecessors: [ WebKit#2 ]
[  29] get_rest_length    dst:loc11, numParametersToSkip:1
...

bb#12
Predecessors: [ WebKit#8 WebKit#9 WebKit#10 ]
[ 138] new_func_exp       dst:loc10, scope:loc4, functionDecl:0
...

bb#13
Predecessors: [ ]
[ 170] catch              exception:loc10, thrownValue:loc8
[ 174] jmp                targetLabel:8(->182)
Successors: [ WebKit#15 ]

bb#14
Predecessors: [ WebKit#7 WebKit#11 ]
[ 176] catch              exception:loc10, thrownValue:loc8
[ 180] jmp                targetLabel:2(->182)
Successors: [ WebKit#15 ]

bb#15
Predecessors: [ WebKit#13 WebKit#14 ]
[ 182] mov                dst:loc12, src:Undefined(const1)
...

Exception Handlers:
	 1: { start: [  20] end: [  29] target: [ 170] } synthesized catch
	 2: { start: [  29] end: [ 138] target: [ 176] } synthesized catch
```

* JSTests/stress/catch-rest-parameter.js: Added.
(throwError):
(shouldThrow):
(async f):
(throwError.async f):
(throwError.async let):
(async let):
(x.async f):
(x):
(async shouldThrow):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:

Canonical link: https://commits.webkit.org/256864@main

    Fix TypeError in parameter destructuring in async function should be a rejected promise
    https://bugs.webkit.org/show_bug.cgi?id=247785
    rdar://102325201

    Reviewed by Yusuke Suzuki.

    Rest parameter should be caught in async function. So, running this
    JavaScript program should print "caught".
    ```
    async function f(...[[]]) { }
    f().catch(e => print("caught"));
    ```

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

    GraalJS
    ```
    $ js input.js
    caught
    ```

    https://tc39.es/ecma262/#sec-async-function-definitions
    ...
    AsyncFunctionDeclaration[Yield, Await, Default] :
        async [no LineTerminator here] function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }
        [+Default] async [no LineTerminator here] function ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }

    AsyncFunctionExpression :
        async [no LineTerminator here] function BindingIdentifier[~Yield, +Await]opt ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody }
    ...

    According to the spec, it indicates `FormalParameters` is used for Async
    Function, where `FormalParameters` can be converted to `FunctionRestParameter`.

    https://tc39.es/ecma262/#sec-parameter-lists
    ...
    FormalParameters[Yield, Await] :
        [empty]
        FunctionRestParameter[?Yield, ?Await]
        FormalParameterList[?Yield, ?Await]
        FormalParameterList[?Yield, ?Await] ,
        FormalParameterList[?Yield, ?Await] , FunctionRestParameter[?Yield, ?Await]
    ...

    And based on RS: EvaluateAsyncFunctionBody, it will invoke the promise.reject
    callback function with abrupt value ([[value]] of non-normal completion record).

    https://tc39.es/ecma262/#sec-runtime-semantics-evaluateasyncfunctionbody
    ...
    2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)).
    3. If declResult is an abrupt completion, then
        a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »).
    ...

    In that case, any non-normal results of evaluating rest parameters should be
    caught and passed to the reject callback function.

    To resolve this problem, we should allow the emitted RestParameterNode be wrapped
    by the catch handler for promise. However, we should remove `m_restParameter` and
    emit rest parameter byte code in `initializeDefaultParameterValuesAndSetupFunctionScopeStack`
    if we can prove that change has no side effect. In that case, we can only use one
    exception handler.

    Current fix is to add another exception handler. And move the handler byte codes to
    the bottom of code block in order to make other byte codes as much compact as possible.

    Input:
    ```
    async function f(arg0, ...[[]]) { }
    f();
    ```

    Dumped Byte Codes:
    ```
    ...

    bb#2
    Predecessors: [ WebKit#1 ]
    [  20] mov                dst:loc9, src:<JSValue()>(const0)
    ...

    bb#3
    Predecessors: [ WebKit#2 ]
    [  29] get_rest_length    dst:loc11, numParametersToSkip:1
    ...

    bb#12
    Predecessors: [ WebKit#8 WebKit#9 WebKit#10 ]
    [ 138] new_func_exp       dst:loc10, scope:loc4, functionDecl:0
    ...

    bb#13
    Predecessors: [ ]
    [ 170] catch              exception:loc10, thrownValue:loc8
    [ 174] jmp                targetLabel:8(->182)
    Successors: [ WebKit#15 ]

    bb#14
    Predecessors: [ WebKit#7 WebKit#11 ]
    [ 176] catch              exception:loc10, thrownValue:loc8
    [ 180] jmp                targetLabel:2(->182)
    Successors: [ WebKit#15 ]

    bb#15
    Predecessors: [ WebKit#13 WebKit#14 ]
    [ 182] mov                dst:loc12, src:Undefined(const1)
    ...

    Exception Handlers:
    	 1: { start: [  20] end: [  29] target: [ 170] } synthesized catch
    	 2: { start: [  29] end: [ 138] target: [ 176] } synthesized catch
    ```

    * JSTests/stress/catch-rest-parameter.js: Added.
    (throwError):
    (shouldThrow):
    (async f):
    (throwError.async f):
    (throwError.async let):
    (async let):
    (x.async f):
    (x):
    (async shouldThrow):
    * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
    (JSC::BytecodeGenerator::BytecodeGenerator):
    (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
    * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:

    Canonical link: https://commits.webkit.org/256864@main

Canonical link: https://commits.webkit.org/252432.994@safari-7614-branch

https://bugs.webkit.org/show_bug.cgi?id=251063
rdar://104585575

Reviewed by Mark Lam and Justin Michaud.

This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace.
The example is as follows.

    frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt]
    frame WebKit#1: 0x000000010ec44204 0x10eccc5dc
    frame WebKit#2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined)
    frame WebKit#3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40)
    frame WebKit#4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40)
    frame WebKit#5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3)
    frame WebKit#6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0)
    frame WebKit#7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0)
    frame WebKit#8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame WebKit#9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame WebKit#10: 0x000000010ec3c728
    frame WebKit#11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt]
    frame WebKit#12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt]
    frame WebKit#13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt]
    frame WebKit#14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt]
    frame WebKit#15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt]
    frame WebKit#16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt]
    ...

* Source/JavaScriptCore/interpreter/CallFrame.cpp:
(JSC::CallFrame::dump const):

Canonical link: https://commits.webkit.org/259262@main

Upgrade to August 3

…utItem) and rename its layout entry points

https://bugs.webkit.org/show_bug.cgi?id=318643

Reviewed by Antti Koivisto.

FlexLayout threaded the render-tree RelayoutChildren flag through layout() and layoutFlexItems only to
hand it to RenderFlexibleBox's per-item layout, even though FlexLayout is meant to reach the render tree
only through the container. The flag is really a property of each item RenderFlexibleBox collects.

Carry it on FlexLayoutItem as shouldInvalidateChildContent, set in collectFlexItems from
relayoutChildren == RelayoutChildren::Yes, and read it in layoutFlexItemWithMainSize. FlexLayout no
longer mentions RelayoutChildren, and the multi-line-column re-resolve no longer passes
RelayoutChildren::No: that was already a no-op, because the !hasFlexItemCompletedLayout guard makes a
re-layout non-forcing regardless.

While here, rename for clarity, mirroring the LFC Layout::FlexLayout the legacy path converges on:
performFlexLayout becomes layout, and layoutFlexItemAfterMainSizing becomes layoutFlexItemWithMainSize
(the point is that the flexed main size is imposed on the item, not that it runs "after" a step). The
line-positioning lambda becomes computeFlexLineCrossPositions (it fills flexLinesCrossPositionList; the
used cross size, 9.6 #15, is resolved later in updateFlexContainerLogicalHeight), which also fixes a
comment that labeled it 9.6 ahead of the 9.5 main-axis step that necessarily precedes it.

No change in behavior.

* Source/WebCore/rendering/RenderFlexLayout.cpp:
* Source/WebCore/rendering/RenderFlexLayout.h:
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/317429@main

…ogicalHeight instead of reading it off the container

https://bugs.webkit.org/show_bug.cgi?id=318648

Reviewed by Antti Koivisto.

FlexLayout read the flex container's used cross size live off the container (crossAxisContentExtent
and crossAxisExtent, via FlexLayoutUtils) in five places: the single-line height, the align-content
pass, the two stretch helpers, and the final item placement. That size is only settled once
updateFlexContainerLogicalHeight has resolved the container's logical height (9.6 #15), so each of
those reads reached back through the container after the fact.

Have updateFlexContainerLogicalHeight return the used cross extents instead, as a
FlexContainerCrossExtents: the content-box extent (line positioning, align-content, and each item's
cross size) and the border-box extent (the right-to-left column flip). layout() captures them once
and threads them to the consumers, so FlexLayout no longer reads the container's cross size anywhere.

No change in behavior.

* Source/WebCore/rendering/RenderFlexLayout.cpp:
* Source/WebCore/rendering/RenderFlexLayout.h:
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
* Source/WebCore/rendering/RenderFlexibleBox.h:

Canonical link: https://commits.webkit.org/317446@main

…s' per-flex-item static helpers

https://bugs.webkit.org/show_bug.cgi?id=320019

Reviewed by Antti Koivisto.

The per-item static helpers in FlexFormattingUtils took the flex container as an
explicit (const RenderFlexibleBox&, const RenderBox& flexItem) pair, even though a
flex item's parent is always the flex container. Drop the container argument from
these twelve statics and derive it internally from the item's parent, mirroring
what ScopedCrossAxisOverrideForFlexItem already does:

    auto& flexBox = downcast<RenderFlexibleBox>(*flexItem.parent());

The two that only forwarded the container to other statics (useContentBasedMinimumSize,
flexBasisForFlexItem) no longer need it at all. All callers drop the container argument:
the utils' own static-to-static calls and instance forwarders, RenderFlexibleBox's proxies
and ScopedCrossAxisOverrideForFlexItem, and LayoutIntegration::FlexLayout (its positioned
flex items are direct out-of-flow children, so their parent is the container too). The
container-only statics (isColumnFlow, isHorizontalFlow, computeGap, ...) still take it.

Also correct the cross-axis step comments in FlexFormattingContext::layout(): they
labelled a section "9.6 (#13 - #16)" although the block also runs the §9.4 steps (#9,
dependency around the container's used-cross-size finalization (#15), not by spec number,
so the comment now says so.

No change in behavior.

* Source/WebCore/layout/formattingContexts/flex/FlexFormattingContext.cpp:
(WebCore::FlexFormattingContext::layout):
* Source/WebCore/layout/formattingContexts/flex/FlexFormattingUtils.cpp:
(WebCore::FlexFormattingUtils::crossAxisMarginExtentForFlexItem):
(WebCore::FlexFormattingUtils::preferredMainSizeLengthForFlexItem):
(WebCore::FlexFormattingUtils::minMainSizeLengthForFlexItem):
(WebCore::FlexFormattingUtils::preferredCrossSizeLengthForFlexItem):
(WebCore::FlexFormattingUtils::mainAxisOverflowForFlexItem):
(WebCore::FlexFormattingUtils::hasAutoMarginsInCrossAxis):
(WebCore::FlexFormattingUtils::useContentBasedMinimumSize):
(WebCore::FlexFormattingUtils::preferredAspectRatioForFlexItem const):
(WebCore::FlexFormattingUtils::needToStretchFlexItemLogicalHeight const):
(WebCore::FlexFormattingUtils::innerCrossSizeForFlexItem):
(WebCore::FlexFormattingUtils::availableAlignmentSpaceForFlexItem const):
(WebCore::FlexFormattingUtils::marginBoxAscentForFlexItem const):
(WebCore::FlexFormattingUtils::mainAxisIsFlexItemInlineAxis):
(WebCore::FlexFormattingUtils::flexBasisForFlexItem):
(WebCore::FlexFormattingUtils::alignmentForFlexItem):
(WebCore::FlexFormattingUtils::hasDefiniteCrossSizeForFlexItem):
(WebCore::FlexFormattingUtils::crossAxisMarginExtentForFlexItem const):
(WebCore::FlexFormattingUtils::preferredMainSizeLengthForFlexItem const):
(WebCore::FlexFormattingUtils::minMainSizeLengthForFlexItem const):
(WebCore::FlexFormattingUtils::preferredCrossSizeLengthForFlexItem const):
(WebCore::FlexFormattingUtils::hasAutoMarginsInCrossAxis const):
(WebCore::FlexFormattingUtils::useContentBasedMinimumSize const):
(WebCore::FlexFormattingUtils::innerCrossSizeForFlexItem const):
(WebCore::FlexFormattingUtils::mainAxisIsFlexItemInlineAxis const):
(WebCore::FlexFormattingUtils::flexBasisForFlexItem const):
(WebCore::FlexFormattingUtils::alignmentForFlexItem const):
(WebCore::FlexFormattingUtils::hasDefiniteCrossSizeForFlexItem const):
* Source/WebCore/layout/formattingContexts/flex/FlexFormattingUtils.h:
* Source/WebCore/layout/integration/flex/LayoutIntegrationFlexLayout.cpp:
(WebCore::LayoutIntegration::FlexLayout::firstLineBaseline const):
(WebCore::LayoutIntegration::FlexLayout::lastLineBaseline const):
(WebCore::LayoutIntegration::FlexLayout::baselineFlexItemInLine const):
(WebCore::LayoutIntegration::FlexLayout::staticCrossAxisPositionForPositionedFlexItem):
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::ScopedCrossAxisOverrideForFlexItem::ScopedCrossAxisOverrideForFlexItem):
(WebCore::RenderFlexibleBox::canUseFlexItemForPercentageResolution):
(WebCore::RenderFlexibleBox::computeBlockAxisContentSizeForFlexItem):
(WebCore::RenderFlexibleBox::setOverridingMainSizeForFlexItem):
(WebCore::RenderFlexibleBox::resetAutoMarginsAndLogicalTopInCrossAxis):
(WebCore::RenderFlexibleBox::useContentBasedMinimumBlockSize const):
(WebCore::RenderFlexibleBox::hasStretchedFlexItemWithAspectRatio const):
(WebCore::RenderFlexibleBox::mainAxisIsFlexItemInlineAxis const):
(WebCore::RenderFlexibleBox::flexBasisForFlexItem const):
(WebCore::RenderFlexibleBox::alignmentForFlexItem const):
(WebCore::RenderFlexibleBox::hasDefiniteCrossSizeForFlexItem const):
(WebCore::RenderFlexibleBox::flexItemMainSizeIsDefinite):

Canonical link: https://commits.webkit.org/317776@main