…arget labels.

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

Reviewed by Saam Barati.

Disassemblies used to look like this:

     0x10e480ff8:    ldurb    w17, [x0, #7]
     0x10e480ffc:    cmp      w17, #0
     0x10e481000:    b.hi   0x10e48103c
     0x10e481004:    stur     x0, [fp, #-72]
     ...
     0x10e481040:    movk     x3, #0xfffe, lsl #48
     0x10e481044:    b        0x10e4814f4
     0x10e481048:    nop

With this patch, it will now look like this:

       <748> 0x10e120aec:    ldurb    w17, [x0, #7]
       <752> 0x10e120af0:    cmp      w17, #0
       <756> 0x10e120af4:    b.hi     0x10e120b30 -> <816>
       <760> 0x10e120af8:    stur     x0, [fp, #-80]
       ...
       <820> 0x10e120b34:    movk     x3, #0xfffe, lsl #48
       <824> 0x10e120b38:    b        0x10e120fc8 -> <1992>
       <828> 0x10e120b3c:    nop

1. Each instruction pc is now prefixed with a pc index i.e. the offset of the
   pc address from the start of the compilation unit e.g. <756>.

2. Relative branches now show the branch target as a pc index (effectively, an
   internal label in this compilation unit) in addition to the pc address e.g.
   the "-> <816>" in:
       <756> 0x10e120af4:    b.hi     0x10e120b30 -> <816>

   Also fixed a formatting bug where the space between relative branch instructions
   and their target pc was short 2 spaces.

3. If the relative branch target is a known thunk, the disassembler will now
   print the thunk label e.g.

       <828> 0x10e12033c:    bl       0x10e0f0a00 -> <thunk: get_from_scope thunk>
      <1476> 0x10e120dc4:    cbnz     x16, 0x10e104100 -> <thunk: handleExceptionWithCallFrameRollback>
      <2368> 0x10e121140:    b        0x10e10c000 -> <thunk: DFG OSR exit generation thunk>

   Introduced a FINALIZE_THUNK macro that will be used instead of FINALIZE_CODE in
   thunk generators.  By doing so, thunk labels will automatically be registered
   with the disassembler, and will be used for the above look up.

   Thunk label registration is only done if disassembly is enabled.

4. If the branch target is neither an internal label nor a thunk, then the
   disassembler will print some useful info about it to the best of its
   knowledge e.g.

       <168> 0x10e1002e8:    b        0x10e120b60 -> <JIT PC>
       <168> 0x10e1002e8:    b        0x10e120b60 -> <LLInt PC>
       <168> 0x10e1002e8:    b        0x10e120b60 -> <unknown>

5. The disassemble() function now takes 2 additional arguments: codeStart, and
   codeEnd.  These are needed so that the disassembler can compute the pc index
   for each instruction, as well as determine if a branch target is internal to
   this compilation unit, or pointing out of it.

This feature is currently only supported for the ARM64 disassembler.

Printing of JIT operation labels (via movz + movk + indirect branch) is not yet
supported.

* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::setIsThunk):
* b3/air/AirDisassembler.cpp:
(JSC::B3::Air::Disassembler::dump):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpDisassembly):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
(JSC::DFG::osrEntryThunkGenerator):
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcode::appendPCRelativeOffset):
(JSC::ARM64Disassembler::A64DOpcodeConditionalBranchImmediate::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcode::A64DOpcode):
(JSC::ARM64Disassembler::A64DOpcode::appendPCRelativeOffset): Deleted.
* disassembler/ARM64Disassembler.cpp:
(JSC::tryToDisassemble):
* disassembler/CapstoneDisassembler.cpp:
(JSC::tryToDisassemble):
* disassembler/Disassembler.cpp:
(JSC::disassemble):
(JSC::disassembleAsynchronously):
(JSC::ensureThunkLabelMap):
(JSC::registerThunkLabel):
(JSC::labelForThunk):
* disassembler/Disassembler.h:
(JSC::tryToDisassemble):
* disassembler/RISCV64Disassembler.cpp:
(JSC::tryToDisassemble):
* disassembler/X86Disassembler.cpp:
(JSC::tryToDisassemble):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/JIT.cpp:
(JSC::JIT::consistencyCheckGenerator):
* jit/JITCall.cpp:
(JSC::JIT::returnFromBaselineGenerator):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dump):
(JSC::JITDisassembler::dumpDisassembly):
* jit/JITDisassembler.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::valueIsFalseyGenerator):
(JSC::JIT::valueIsTruthyGenerator):
(JSC::JIT::op_throw_handlerGenerator):
(JSC::JIT::op_enter_handlerGenerator):
(JSC::JIT::op_check_traps_handlerGenerator):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::slow_op_get_by_val_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_get_private_name_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_put_by_val_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_put_private_name_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_del_by_id_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_del_by_val_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_get_by_id_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_get_by_id_with_this_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::slow_op_put_by_id_callSlowOperationThenCheckExceptionGenerator):
(JSC::JIT::generateOpResolveScopeThunk):
(JSC::JIT::slow_op_resolve_scopeGenerator):
(JSC::JIT::generateOpGetFromScopeThunk):
(JSC::JIT::slow_op_get_from_scopeGenerator):
(JSC::JIT::slow_op_put_to_scopeGenerator):
* jit/SlowPathCall.cpp:
(JSC::JITSlowPathCall::generateThunk):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::finalize):
* jit/ThunkGenerator.h:
* jit/ThunkGenerators.cpp:
(JSC::handleExceptionGenerator):
(JSC::handleExceptionWithCallFrameRollbackGenerator):
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
(JSC::checkExceptionGenerator):
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::linkCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::arityFixupGenerator):
(JSC::unreachableGenerator):
(JSC::stringGetByValGenerator):
(JSC::boundFunctionCallGenerator):
(JSC::remoteFunctionCallGenerator):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::generateThunkWithJumpToPrologue):
(JSC::LLInt::generateThunkWithJumpToLLIntReturnPoint):
(JSC::LLInt::createJSGateThunk):
(JSC::LLInt::createWasmGateThunk):
(JSC::LLInt::createTailCallGate):
(JSC::LLInt::tagGateThunk):
(JSC::LLInt::untagGateThunk):
* yarr/YarrDisassembler.cpp:
(JSC::Yarr::YarrDisassembler::dump):
(JSC::Yarr::YarrDisassembler::dumpDisassembly):
* yarr/YarrDisassembler.h:

Canonical link: https://commits.webkit.org/250547@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294180 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…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

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

Reviewed by Antti Koivisto.

RenderSlider::computeIntrinsicLogicalWidths should check against _logical_ width value.

* LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/flex-item-compressible-002-expected.txt:
* Source/WebCore/rendering/RenderSlider.cpp:
(WebCore::RenderSlider::computeIntrinsicLogicalWidths const):

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

Reviewed by NOBODY (OOPS!).

This was spotted by ASan, the real and imaginary AudioFloatArrays end-up using aligned_alloc() for
their storage, which expects a power-of-two size. Using fftSize / 2 + 1 makes the size
non-power-of-two, the full fftSize being power-of-two (we now have an ASSERT for this).

==1733723==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fc75c438bca bp 0x7ffed612c860 sp 0x7ffed612c028 T0)
==1733723==The signal is caused by a WRITE memory access.
==1733723==Hint: address points to the zero page.
    #0 0x7fc75c438bca in __memset_avx2_unaligned_erms (/lib64/libc.so.6+0x16dbca) (BuildId: 77c77fee058b19c6f001cf2cb0371ce3b8341211)
    WebKit#1 0x2fc4ce in __asan_memset (/var/home/phil/WebKit/local-build-gtk/WebKitBuild/GTK/Release/bin/WebKitWebProcess+0x2fc4ce) (BuildId: e2b0aff0c8fcab48026d63cf711cd70d0aeceb79)
    WebKit#2 0x7fc77047599e in WebCore::FFTFrame::FFTFrame(unsigned int) UnifiedSource-3c72abbe-20.cpp
    WebKit#3 0x7fc76d41c08b in WebCore::PeriodicWave::createBandLimitedTables(float const*, float const*, unsigned int, WebCore::ShouldDisableNormalization) UnifiedSource-f8afad56-52.cpp
    WebKit#4 0x7fc76d41f371 in WebCore::PeriodicWave::generateBasicWaveform(WebCore::PeriodicWave::Type) UnifiedSource-f8afad56-52.cpp
    WebKit#5 0x7fc76d41e633 in WebCore::PeriodicWave::createSine(float) UnifiedSource-f8afad56-52.cpp
    WebKit#6 0x7fc76d3c2352 in WebCore::BaseAudioContext::periodicWave(WebCore::OscillatorType) UnifiedSource-f8afad56-49.cpp
    WebKit#7 0x7fc76d410dbf in WebCore::OscillatorNode::setTypeForBindings(WebCore::OscillatorType) UnifiedSource-f8afad56-52.cpp
    WebKit#8 0x7fc76d4102f4 in WebCore::OscillatorNode::create(WebCore::BaseAudioContext&, WebCore::OscillatorOptions const&) UnifiedSource-f8afad56-52.cpp
    WebKit#9 0x7fc76d3bc210 in WebCore::BaseAudioContext::createOscillator() UnifiedSource-f8afad56-49.cpp
    WebKit#10 0x7fc76acbc743 in WebCore::jsBaseAudioContextPrototypeFunction_createOscillator(JSC::JSGlobalObject*, JSC::CallFrame*) UnifiedSource-3a52ce78-11.cpp
    WebKit#11 0x7fc705c10037  (<unknown module>)

* Source/WebCore/platform/audio/gstreamer/FFTFrameGStreamer.cpp:
(WebCore::FFTFrame::FFTFrame):

…ate-event/intercept-detach-multiple.html is crashing

https://bugs.webkit.org/show_bug.cgi?id=297414
rdar://158349001

Reviewed by Ben Nham.

The Navigation API spec in Step WebKit#7 here:
(https://html.spec.whatwg.org/multipage/browsing-the-web.html#getting-session-history-entries-for-the-navigation-api)
says that when getting the entries, we should start at index
(startingIndex - 1) and work backwards while prepending the
entries to our list. The code wasn't doing that. It was starting
at 0 and working up to (startingIndex - 1). Given that we break
if we see an entry with a different domain, that means that in
the scenario where the entries before (startingIndex - 1) are:

1. foo.com
2. foo.com#A
3. bar.com
4. foo.com#B
5. current entry (of foo.com origin)

And the origin we're filtering by is foo.com, the entries we'll
end up with are:

1. foo.com
2. foo.com#A

Whereas we should have ended up with:

1. foo.com#B

m_entries corresponds to the entries that this navigation object
can navigate the frame to. It cannot go from entry 5 to 2 because
that would have gone to 3 first and cross-origin navigation aren't
allowed by this API. So 2 should not be in the list at all.

That's what is happening in this test. The entries in the list
are incorrect and leading to an error down the line.

* LayoutTests/TestExpectations:
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::initializeForNewWindow):

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

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

Reviewed by Yusuke Suzuki.

This PR includes seveal changes to improve the codegen of store/load:
* Optimized storePair to use a single move when constants are equal
* Eliminated register materialization for constant integer store
* Constant pointer folding when they are statically known

One example where these work together is I64Store, before:

    [   0x22d] I64Store
              0xf1a22bcc: ldrd r1, r2, [r10, #0x34]
              0xf1a22bd0: movw r0, #0x5d18
              0xf1a22bd4: mov r5, r0
              0xf1a22bd6: adds r5, r5, WebKit#7
              0xf1a22bd8: bhs.w #0xf1a22c44
              0xf1a22bdc: cmp r5, r2
              0xf1a22bde: bhs.w #0xf1a22c44
              0xf1a22be2: mov r5, r0
              0xf1a22be4: add r5, r1
              0xf1a22be6: movs r4, #0
              0xf1a22be8: movs r3, #0
              0xf1a22bea: str r3, [r5]
              0xf1a22bec: str r4, [r5, #4]

after:

    [   0x22d] I64Store
              0xf1b22c50: ldrd r1, r2, [r10, #0x34]
              0xf1b22c54: movw r5, #0x5d1f
              0xf1b22c58: cmp r5, r2
              0xf1b22c5a: bhs.w #0xf1b22cc0
              0xf1b22c5e: movw r12, #0x5d18
              0xf1b22c62: add.w r5, r1, r12
              0xf1b22c66: mov.w r12, #0
              0xf1b22c6a: str.w r12, [r5]
              0xf1b22c6e: str.w r12, [r5, #4]

On JetStream3's tfjs-wasm.js, we reduce the code size by -9,5KiB:

Base total code size: 433254 bytes (424KiB)
New total code size: 423578 bytes (414KiB)

Difference (new - base): -9676 bytes (-9,5KiB)
Percentage change: -2.23%

* Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::store16):
(JSC::MacroAssemblerARMv7::storePair32):
* Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::store):
* Source/JavaScriptCore/wasm/WasmBBQJIT32_64.h:
(JSC::Wasm::BBQJITImpl::BBQJIT::emitCheckAndPrepareAndMaterializePointerApply):

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

…ems and crossSizeForFlexLines

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

Reviewed by Antti Koivisto.

Cross sizing was fused into one per-line function (returning the line's extent,
its baseline groups, and the next offset at once) wrapped by
computeCrossSizeForFlexLines. FlexLayout::layout splits it instead: #7
hypotheticalCrossSizeForFlexItems returns each item's hypothetical cross size,
and #8 crossSizeForFlexLines turns those into each line's cross size. Match that
shape -- both now return plain Vector<LayoutUnit> lists, so an FFC body ports in.

crossSizeForFlexLines keeps legacy's line-size arithmetic (the running
first/last-baseline maxes with a shared descent), so this preserves behavior
rather than adopting FFC's group max. The row-flow container height growth moves
to the line-state assembly (once per line by the line's cross size, which equals
the old per-item maximum), and the baseline sharing groups are built in
performBaselineAlignment where they are used -- safe because baseline items are
never align-self:stretch, so nothing relayouts them between sizing and alignment.
LineState no longer carries the groups.

performFlexLayout now runs its sizing and alignment phases as
performContentSizing() and performContentAlignment() lambdas, matching
FlexLayout::layout. layoutFlexLines, computeCrossSizeForFlexLines, and the
FlexLineResult struct are gone.

No change in behavior.

* Source/WebCore/rendering/RenderFlexibleBox.h:
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::LineState::LineState):
(WebCore::RenderFlexibleBox::performFlexLayout):
(WebCore::RenderFlexibleBox::hypotheticalCrossSizeForFlexItems):
(WebCore::RenderFlexibleBox::crossSizeForFlexLines):
(WebCore::RenderFlexibleBox::handleCrossAxisAlignmentForFlexItems):
(WebCore::RenderFlexibleBox::performBaselineAlignment):
(WebCore::RenderFlexibleBox::computeCrossSizeForFlexLines): Deleted.
(WebCore::RenderFlexibleBox::layoutFlexLines): Deleted.

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