Timeline

Aug 8, 2021:

7:09 PM Changeset in webkit [280768] by Russell Epstein

• 1 copy in tags/Safari-612.1.27.0.3

Tag Safari-612.1.27.0.3.

6:21 PM Changeset in webkit [280767] by Wenson Hsieh

• 14 edits
  2 adds in trunk

caret-color does not work on first click in ios
​https://bugs.webkit.org/show_bug.cgi?id=228859
rdar://81674787

Reviewed by Tim Horton.

Source/WebKit:

Addresses a couple of issues that cause the caret-color CSS property to not be applied when focusing editable
content on iOS. See below for more details.

Test: editing/caret/ios/caret-color-after-refocusing-input.html

• Platform/spi/ios/UIKitSPI.h:
• UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
• UIProcess/API/ios/WKWebViewTestingIOS.mm:

(-[WKWebView _serializedSelectionCaretBackgroundColorForTesting]):

Add support for a new test-only helper method. See Tools/ChangeLog for more information.

• UIProcess/ios/WKContentViewInteraction.h:
• UIProcess/ios/WKContentViewInteraction.mm:

(WebKit::WKSelectionDrawingInfo::WKSelectionDrawingInfo):
(WebKit::operator==):
(WebKit::operator<<):

Make a minor adjustment to ensure that changes to caretColor in EditorState are propagated to UIKit's
selection views. To achieve this, we add caretColor to WKSelectionDrawingInfo, and force the text selection
view to update the caret background color when the caret color changes (alongside other selection UI geometry
changes, which are applied underneath the call to -selectionChanged).

(-[WKContentView _updateChangedSelection:]):
(-[WKContentView textInteractionAssistant]):

• WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::getPlatformEditorState const):

Address an existing FIXME which (mostly) fixes this bug. Currently, the caret color is only computed when
WebPage::m_focusedElement is set. However, when resigning first responder, we clear out WebPage's
m_focusedElement) right before updating the DOM selection, which creates a brief window during which we
compute an EditorState with a caretColor of transparent black.

To avoid this inconsistency, we instead compute the caret color from the selection container; this has the
additional benefit of allowing the caret color to change when changing selection within a single editable host
with multiple caret colors (instead of always just using the focused element's caret color).

Note that while this adjustment to WebPage::getPlatformEditorState is sufficient to ensure that the value of
-[WKContentView insertionPointColor] (which is based on EditorState) is always up-to-date, this doesn't
guarantee that the actual color of UIKit's caret view reflects the updated -insertionPointColor, which results
in situations where the caret color appears out-of-date after hiding the keyboard and refocusing an input field.
To fix this, we need the other adjustment in WKContentView (see above).

Tools:

Make it possible to test this bug by adding a UIScriptController hook to request the background color of the
current selection view's caret view, as serialized CSS text. See LayoutTests/ChangeLog for more details.

• TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
• TestRunnerShared/UIScriptContext/UIScriptController.h:

(WTR::UIScriptController::selectionCaretBackgroundColor const):

• WebKitTestRunner/ios/UIScriptControllerIOS.h:
• WebKitTestRunner/ios/UIScriptControllerIOS.mm:

(WTR::UIScriptControllerIOS::selectionCaretBackgroundColor const):

LayoutTests:

Add a new layout test that exercises the issue, as reported in Bugzilla (the call to -resignFirstResponder
simulates backgrounding Safari). To achieve this, we also introduce a script controller testing helper to grab
the native background color of the UITextSelectionView's caret view; see Tools/ChangeLog for more details.

• editing/caret/ios/caret-color-after-refocusing-input-expected.txt: Added.
• editing/caret/ios/caret-color-after-refocusing-input.html: Added.
• resources/ui-helper.js:

(window.UIHelper.selectionCaretBackgroundColor):

2:53 PM Changeset in webkit [280766] by jer.noble@apple.com

• 5 edits in trunk

REGRESSION: http/tests/preload/onload_event.html is a flaky timeout on Big Sur wk1 Release
​https://bugs.webkit.org/show_bug.cgi?id=227366
<rdar://problem/79733280>

Reviewed by Eric Carlson.

Source/WebCore:

Querying for any state on an AVAsset before its fully loaded will cause AVFoundation to block
on networking to fulfill the request, and in the case where WebKit handles loading, will eventually
dispatch to the main thread (which is blocked) in WebCore loader code, causing a deadlock.

Always guard queries to AVAsset with checks for the loaded status of the property being queried.
To make this easier, add a new safeAVAssetTracksForVisualMedia() method, similar to the existing
safeAVAssetTracksForAudibleMedia(), which checks the "tracks" property status and returns an empty
array if the tracks are not yet loaded.

Guard a few more methods by bailing early if the AVAsset is not fully loaded.

• platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
• platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:

(WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged):
(WebCore::MediaPlayerPrivateAVFoundationObjC::updateRotationSession):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintWithVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::safeAVAssetTracksForVisualMedia):

LayoutTests:

• platform/mac-wk1/TestExpectations:

1:43 PM Changeset in webkit [280765] by ysuzuki@apple.com

• 3 edits in trunk/JSTests

[JSC] Clean up test262 expectations
​https://bugs.webkit.org/show_bug.cgi?id=228903

Reviewed by Ross Kirsling.

• test262/config.yaml:
• test262/expectations.yaml:

Aug 7, 2021:

9:18 PM Changeset in webkit [280764] by ddkilzer@apple.com

• 2 edits in trunk/Source/WebCore

UBSan: KeyboardScrollingAnimator.cpp:303:10: runtime error: load of value nnn, which is not a valid value for type 'bool'
<​https://webkit.org/b/228901>

Reviewed by Tim Horton.

Covered by running 78 layout tests with UBSan enabled.

• platform/KeyboardScrollingAnimator.h:
• Initialize m_scrollTriggeringKeyIsPressed to false.

6:20 PM Changeset in webkit [280763] by aakash_jain@apple.com

• 2 edits in trunk/Tools

[ews] Limit the size of error context buffer
​https://bugs.webkit.org/show_bug.cgi?id=228900

Reviewed by Alexey Proskuryakov.

• CISupport/ews-build/steps.py:

(BuildLogLineObserver.outLineReceived): Limit the lines for additional context to 50 lines.

3:47 PM Changeset in webkit [280762] by Wenson Hsieh

• 7 edits
  2 adds in trunk

[macOS] Web process crashes when detaching Document with uncommitted marked text
​https://bugs.webkit.org/show_bug.cgi?id=228841
rdar://79960890

Reviewed by Ryosuke Niwa.

Source/WebCore:

In the case where the document is in the process of being detached (underneath willBeRemovedFromFrame()), if
there is currently uncommitted marked text in the document, we will attempt to cancel the IME composition in the
process of clearing out the selection. On macOS, this calls into Editor::cancelComposition() which
subsequently triggers layout under various call stacks (DOM mutations, text event dispatch, and when scrolling
to reveal the selection); this triggers a security release assertion inside Document::updateLayout().

To mitigate this, we avoid calling into this codepath if the Document no longer has a living render tree (i.e.,
the render tree has either been destroyed, is being destroyed, or has not been created yet).

Test: editing/inserting/remove-frame-with-marked-text.html

• editing/mac/EditorMac.mm:

(WebCore::Editor::selectionWillChange):

Source/WebKit:

Deploy a similar fix on iOS, to avoid any attempts to compute editor state due to discarding uncommitted marked
text during Document teardown. This is required in order to avoid the same security assertion when running the
new layout test on iOS.

• WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::sendEditorStateUpdate):

Tools:

Make a small adjustment to DumpRenderTree, such that TextInputController targets the selected frame (or the main
frame, if there is no DOM selection). This behavior matches that of WebKitTestRunner, and allows layout tests
that use TextInputController to simulate setting marked text inside subframes.

• DumpRenderTree/mac/TextInputControllerMac.m:

(-[TextInputController selectedOrMainFrame]):
(-[TextInputController textInput]):

LayoutTests:

Add a layout test to exercise the crash.

• editing/inserting/remove-frame-with-marked-text-expected.txt: Added.
• editing/inserting/remove-frame-with-marked-text.html: Added.

3:40 PM Changeset in webkit [280761] by commit-queue@webkit.org

• 4 edits in trunk/Source/JavaScriptCore

Fix ODR violations in JSC
​https://bugs.webkit.org/show_bug.cgi?id=228876

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-07
Reviewed by Yusuke Suzuki.

When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule.
JSC currently has two violations. The first is JSC::SpeciesConstructResult, which has two
different declarations, one in ArrayPrototype.cpp and the other in
JSArrayBufferPrototype.cpp. I decided to change the version in ArrayPrototype.cpp to make
the declarations match.

The next problem is JSC::SignalContext. We have two different versions of this struct, one
in VMTraps.cpp and the other in SigillCrashAnalyzer.cpp. In this case, I decided to change
the one in VMTraps.cpp from JSC::SignalContext to JSC::VMTraps::SignalContext.

• runtime/ArrayPrototype.cpp:
• runtime/VMTraps.cpp:

(JSC::VMTraps::tryInstallTrapBreakpoints):

• runtime/VMTraps.h:

2:38 PM Changeset in webkit [280760] by keith_miller@apple.com

• 68 edits
  11 adds in trunk

for-in should only emit one loop in bytecode
​https://bugs.webkit.org/show_bug.cgi?id=227989

Reviewed by Yusuke Suzuki.

JSTests:

• microbenchmarks/for-in-double-array-with-own-named.js: Added.

(test):

• microbenchmarks/for-in-double-array.js: Added.

(test):

• microbenchmarks/for-in-getters.js: Added.

(test):

• microbenchmarks/for-in-int32-array-with-own-named.js: Added.

(test):

• microbenchmarks/for-in-int32-array.js: Added.

(test):

• microbenchmarks/for-in-int32-object-with-own-named-and-getters.js: Added.

(test):

• microbenchmarks/for-in-int32-object-with-own-named.js: Added.

(test):

• microbenchmarks/for-in-object-with-own-named.js: Added.

(sum):
(opaqueSet):

• microbenchmarks/for-in-string-array.js: Added.

(test):

• microbenchmarks/for-of-iterate-array-map-set.js: Added.

(sum):
(let.generator):

• stress/for-in-array-mode.js:

(test):

• stress/for-in-base-reassigned-later.js:
• stress/for-in-delete-during-iteration.js:
• stress/for-in-primitive-index-on-prototype.js: Added.

(test):

• stress/for-in-tests.js:
• stress/has-own-property-structure-for-in-loop-correctness.js:

(test5):

Source/JavaScriptCore:

This patch redesigns how we implement for-in loops. Before this patch we would emit three copies of the for-in loop body. One for the indexed properties, one for the named-own properties, and one for generic properties (anything else). This had a couple of problems. Firstly, it meant bytecode size grew exponentially to number of nested for-in loops. This in turn meant DFG/FTL compilation took much longer.

Going off our experience with fast for-of, this patch turns for-in loops specializations into
a "fused" opcode that internally switches on the enumeration mode it currently sees. For example, if we are enumerating an own-named property, the new enumerator_get_by_val bytecode will check the enumerator cell's cached structure matches the base's then load the property offset directly.

There are four new opcodes this patch adds, which replace the various operations we had for the specialized loops previously. The new opcodes are EnumeratorGetByVal, EnumeratorInByVal, EnumeratorHasOwnProperty, and EnumeratorNext. The first three correspond to GetByVal, InByVal, and HasOwnProperty respectively. The EnumeratorNext opcode has three results in bytecode, the next enumeration value's mode, the index of the property name, and the property name string itself. When enumeration is done EnumeratorNext returns JS null as the property name string. Since the DFG doesn't support tuples yet this opcode is spilt into four new nodes. The first computes the updated index and mode for the next enumeration key, which is encoded into a single JS number. Then there are two nodes that extract the mode and index. Finally, the last new node produces the property name string or null based on the extracted mode and index.

Since, in most benchmarks, any given enumeration opcode tends to profile exactly one enumeration mode. This patch focuses primarily on reimplementing all the optimizations we have for any one specific mode. This means there are still potential optimizations for the multi-mode flavors of each new opcode.

The main optimizations implemented for each new opcode are:

EnumeratorNext:
1) IndexedMode loops are loaded and checked for presence inline (DFG/FTL).
2) NamedMode is computed inline as long as the cached structure on the enumerator cell matches the base (Baseline+). This can only differ if there's a transition.
3) property names are extracted from the cached buffer inline (Baseline+).

EnumeratorGetByVal:
EnumeratorInByVal:
EnumeratorHasOwnProperty:
1) IndexedMode has all the optimizations of a normal XByVal on indexed properties (DFG/FTL).
2) NamedMode will extract the value directly from the inline/out-of-line offset if the structure matches the enumerator's (Baseline+).

There are also a few interesting changes worth mentioning here:
1) If a for-in loop would produce an empty enumerator we now always
return the VMs empty enumerator. This has two benefits, most importantly, it distingishes between an unprofiled for-in loop and empty enumeration, which prevents OSR exit loops. Also, it means that the various Enumerator opcodes no longer need to handle undefined/null when toObjecting the base value.

2) The enumerator now contains a bit set of all the modes it will produce. This removes a few extra branches when speculating on the modes we will see in EnumeratorNext.

3) In the DFG, enumerator GetByVal relies on compileGetByVal to set the result it also passes a prefix callback which emits code after the various cases set up their operands but before code is emitting to help satisfy the branch over register allocation validation. Also, the array mode branch in compileGetByVal passes the data format that it would prefer, which for normal GetByVal is returned. For EnumeratorGetByVal, that preference is completely ignored and it always returns DataFormatJS.

• assembler/MacroAssemblerARM64.h:

(JSC::MacroAssemblerARM64::or8):

• assembler/MacroAssemblerX86Common.h:

(JSC::MacroAssemblerX86Common::or8):

• assembler/MacroAssemblerX86_64.h:

(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::or8): Deleted.

• builtins/BuiltinNames.h:
• bytecode/BytecodeList.rb:
• bytecode/BytecodeUseDef.cpp:

(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):

• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::finishCreation):

• bytecode/LinkTimeConstant.h:
• bytecode/Opcode.h:
• bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::recordHasOwnPropertyInForInLoop):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitEnumeratorNext):
(JSC::BytecodeGenerator::emitEnumeratorHasOwnProperty):
(JSC::BytecodeGenerator::pushForInScope):
(JSC::BytecodeGenerator::popForInScope):
(JSC::rewriteOp):
(JSC::ForInContext::finalize):
(JSC::BytecodeGenerator::findForInContext):
(JSC::BytecodeGenerator::recordHasOwnStructurePropertyInForInLoop): Deleted.
(JSC::BytecodeGenerator::emitGetEnumerableLength): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableIndexedProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableProperty): Deleted.
(JSC::BytecodeGenerator::emitHasOwnStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): Deleted.
(JSC::BytecodeGenerator::emitToIndexString): Deleted.
(JSC::BytecodeGenerator::pushIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::popIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::pushStructureForInScope): Deleted.
(JSC::BytecodeGenerator::popStructureForInScope): Deleted.
(JSC::StructureForInContext::finalize): Deleted.
(JSC::IndexedForInContext::finalize): Deleted.
(JSC::BytecodeGenerator::findStructureForInContext): Deleted.

• bytecompiler/BytecodeGenerator.h:

(JSC::ForInContext::isValid const):
(JSC::ForInContext::invalidate):
(JSC::ForInContext::local const):
(JSC::ForInContext::propertyName const):
(JSC::ForInContext::propertyOffset const):
(JSC::ForInContext::enumerator const):
(JSC::ForInContext::mode const):
(JSC::ForInContext::ForInContext):
(JSC::ForInContext::bodyBytecodeStartOffset const):
(JSC::ForInContext::type const): Deleted.
(JSC::ForInContext::isIndexedForInContext const): Deleted.
(JSC::ForInContext::isStructureForInContext const): Deleted.
(JSC::ForInContext::asIndexedForInContext): Deleted.
(JSC::ForInContext::asStructureForInContext): Deleted.
(JSC::StructureForInContext::StructureForInContext): Deleted.
(JSC::StructureForInContext::index const): Deleted.
(JSC::StructureForInContext::property const): Deleted.
(JSC::StructureForInContext::enumerator const): Deleted.
(JSC::StructureForInContext::baseVariable const): Deleted.
(JSC::StructureForInContext::addGetInst): Deleted.
(JSC::StructureForInContext::addInInst): Deleted.
(JSC::StructureForInContext::addHasOwnPropertyJump): Deleted.
(JSC::IndexedForInContext::IndexedForInContext): Deleted.
(JSC::IndexedForInContext::index const): Deleted.
(JSC::IndexedForInContext::addGetInst): Deleted.

• bytecompiler/NodesCodegen.cpp:

(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):

• dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

• dfg/DFGArrayMode.h:

(JSC::DFG::ArrayMode::isSaneChain const):

• dfg/DFGBackwardsPropagationPhase.cpp:

(JSC::DFG::BackwardsPropagationPhase::propagate):

• dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::parseBlock):

• dfg/DFGCFAPhase.cpp:

(JSC::DFG::CFAPhase::injectOSR):

• dfg/DFGCapabilities.cpp:

(JSC::DFG::capabilityLevel):

• dfg/DFGClobberize.h:

(JSC::DFG::clobberize):

• dfg/DFGDoesGC.cpp:

(JSC::DFG::doesGC):

• dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::setJSArraySaneChainIfPossible):

• dfg/DFGGraph.cpp:

(JSC::DFG::Graph::dump):

• dfg/DFGIntegerRangeOptimizationPhase.cpp:
• dfg/DFGMayExit.cpp:
• dfg/DFGNode.h:

(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasStorageChild const):
(JSC::DFG::Node::storageChildIndex):
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::hasEnumeratorMetadata const):
(JSC::DFG::Node::enumeratorMetadata):

• dfg/DFGNodeType.h:
• dfg/DFGOpInfo.h:

(JSC::DFG::OpInfo::OpInfo):

• dfg/DFGOperations.cpp:

(JSC::DFG::JSC_DEFINE_JIT_OPERATION):

• dfg/DFGOperations.h:
• dfg/DFGPredictionPropagationPhase.cpp:
• dfg/DFGSSALoweringPhase.cpp:

(JSC::DFG::SSALoweringPhase::handleNode):

• dfg/DFGSafeToExecute.h:

(JSC::DFG::safeToExecute):

• dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName):
(JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty):
(JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
(JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileToIndexString): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructurePropertyImpl): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileInStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetDirectPname): Deleted.

• dfg/DFGSpeculativeJIT.h:

(JSC::DFG::SpeculativeJIT::allocate):
(JSC::DFG::JSValueOperand::regs):
(JSC::DFG::JSValueOperand::gpr):
(JSC::DFG::StorageOperand::StorageOperand):
(JSC::DFG::StorageOperand::~StorageOperand):
(JSC::DFG::StorageOperand::emplace):
(JSC::DFG::JSValueRegsTemporary::operator bool):
(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):

• dfg/DFGSpeculativeJIT32_64.cpp:

(JSC::DFG::SpeculativeJIT::compileGetByVal):
(JSC::DFG::SpeculativeJIT::compile):

• dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compileGetByVal):
(JSC::DFG::SpeculativeJIT::compile):

• dfg/DFGTypeCheckHoistingPhase.cpp:

(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):

• ftl/FTLAbstractHeapRepository.h:
• ftl/FTLCapabilities.cpp:

(JSC::FTL::canCompile):

• ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAtImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):

• ftl/FTLOutput.h:

(JSC::FTL::Output::phi):

• generator/DSL.rb:
• interpreter/Register.h:
• interpreter/RegisterInlines.h:

(JSC::Register::operator=):

• jit/AssemblyHelpers.h:
• jit/JIT.cpp:

(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):

• jit/JIT.h:
• jit/JITOpcodes.cpp:

(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.

• jit/JITOpcodes32_64.cpp:

(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.

• jit/JITPropertyAccess.cpp:

(JSC::JIT::generateGetByValSlowCase):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_enumerator_has_propertyImpl):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):

• jit/JITPropertyAccess32_64.cpp:

(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):

• llint/LowLevelInterpreter.asm:
• llint/LowLevelInterpreter64.asm:
• runtime/CommonSlowPaths.cpp:

(JSC::JSC_DEFINE_COMMON_SLOW_PATH):

• runtime/CommonSlowPaths.h:
• runtime/FileBasedFuzzerAgent.cpp:

(JSC::FileBasedFuzzerAgent::getPredictionInternal):

• runtime/FileBasedFuzzerAgentBase.cpp:

(JSC::FileBasedFuzzerAgentBase::opcodeAliasForLookupKey):

• runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::init):

• runtime/JSPropertyNameEnumerator.cpp:

(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::computeNext):

• runtime/JSPropertyNameEnumerator.h:

(JSC::propertyNameEnumerator):

• runtime/PredictionFileCreatingFuzzerAgent.cpp:

(JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal):

1:55 PM Changeset in webkit [280759] by aakash_jain@apple.com

• 3 edits in trunk/Tools

[ews] Ensure file handle is not leaked in loadConfig.py
​https://bugs.webkit.org/show_bug.cgi?id=228866

Reviewed by Alexey Proskuryakov.

• CISupport/build-webkit-org/loadConfig.py:

(loadBuilderConfig):

• CISupport/ews-build/loadConfig.py:

(loadBuilderConfig):

11:50 AM Changeset in webkit [280758] by mmaxfield@apple.com

• 36 edits
  6 copies in trunk/Source

Deduplicate logging channel algorithms
​https://bugs.webkit.org/show_bug.cgi?id=228809

Reviewed by Fujii Hironori.

Source/WebCore:

No new tests because there is no behavior change.

• Sources.txt:
• WebCore.xcodeproj/project.pbxproj:
• accessibility/AXLogger.cpp:
• inspector/agents/page/PageConsoleAgent.cpp:
• page/Page.cpp:
• platform/LogInitialization.cpp: Copied from Source/WebCore/platform/LogInitialization.h.

(WebCore::logChannels):
(WebCore::getLogChannel):

• platform/LogInitialization.h:
• platform/Logging.cpp:

(WebCore::isLogChannelEnabled): Deleted.
(WebCore::setLogChannelToAccumulate): Deleted.
(WebCore::clearAllLogChannelsToAccumulate): Deleted.
(WebCore::initializeLogChannelsIfNecessary): Deleted.
(WebCore::getLogChannel): Deleted.

• platform/Logging.h:
• testing/js/WebCoreTestSupport.cpp:

(WebCoreTestSupport::setLogChannelToAccumulate):
(WebCoreTestSupport::clearAllLogChannelsToAccumulate):
(WebCoreTestSupport::initializeLogChannelsIfNecessary):

Source/WebKit:

• GPUProcess/GPUConnectionToWebProcess.cpp:
• GPUProcess/GPUProcess.cpp:

(WebKit::GPUProcess::initializeGPUProcess):

• Platform/LogInitialization.cpp: Copied from Source/WebKit/Shared/WebKit2Initialize.cpp.

(WebKit::logChannels):
(WebKit::getLogChannel):

• Platform/LogInitialization.h:
• Platform/Logging.cpp:

(WebKit::initializeLogChannelsIfNecessary): Deleted.
(WebKit::getLogChannel): Deleted.

• Platform/Logging.h:
• Shared/AuxiliaryProcess.cpp:

(WebKit::AuxiliaryProcess::initialize):

• Shared/WebKit2Initialize.cpp:

(WebKit::InitializeWebKit2):

• Sources.txt:
• UIProcess/WebPageProxy.cpp:
• UIProcess/WebProcessPool.cpp:
• WebKit.xcodeproj/project.pbxproj:
• WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::platformInitializeWebProcess):

Source/WebKitLegacy:

• WebKitLegacy.xcodeproj/project.pbxproj:

Source/WebKitLegacy/mac:

• Misc/WebKitLogInitialization.h: Copied from Source/WebKit/Platform/LogInitialization.h.
• Misc/WebKitLogInitialization.mm: Copied from Source/WebKitLegacy/mac/Misc/WebKitLogging.m.

(WebKit::logChannels):
(ReportDiscardedDelegateException):

• Misc/WebKitLogging.h:
• Misc/WebKitLogging.m:

(ReportDiscardedDelegateException): Deleted.

• WebCoreSupport/WebDragClient.mm:
• WebView/WebDelegateImplementationCaching.mm:
• WebView/WebView.mm:

(-[WebView _commonInitializationWithFrameName:groupName:]):

Source/WTF:

The current infrastructure (before this patch) had the following duplicated for each framework:

• A .cpp file declared the list of logging channels for that framework
• The .cpp file also had algorithms to search, modify, and initialize these logging channels

Each framework's .cpp file had duplicate algorithms. (The initialization algorithm was even
duplicated 3 times!)

Because the algorithms directly name their specific list of logging channels, a naive deduplication
would have had to add new parameters to these algorithms to pass in the appropriate framework's
list. That's fine, but this is exactly the sort of thing classes were designed for - classes are
an association of algorithms and data. The algorithms are shared but the data isn't, which really
just means we should have 3 instances of a shared class - one for the 3 sets of data.

So, this patch creates the LogChannels class which contains the deduplicated algorithms, and each
framework has a NeverDestroyed singleton instance of that class. There is a single virtual method
in the class, so the appropriate "default write" variable can be queried for each framework.

The instances cannot be declared in the Logging.h files in the frameworks, because certain WebKit2
files want to initialize all 3 instances of LogChannels, but you can't #include multiple Logging.h
files at the same time because their LOG_CHANNEL_PREFIX #defines will collide with each other.
Luckily, LogInitialization.h files exist exactly to solve this purpose, so that's where the
LogChannels instances are declared in. After this change, the Logging.h files are just for the
declarations of the logging channels themselves, and the LogInitialization.h files are for the
LogChannels instances which contain the searching/modifying/initializing algorithms on the list of
logging channels. If you just want to LOG(...) something, #include the relevant Logging.h file, and
if you want to search/modify/initialize across the entire list of channels, then #include the
relevant LogInitialization.h file.

• WTF.xcodeproj/project.pbxproj:
• wtf/CMakeLists.txt:
• wtf/LogChannels.cpp: Copied from Source/WebCore/platform/Logging.cpp.

(WTF::LogChannels::isLogChannelEnabled):
(WTF::LogChannels::setLogChannelToAccumulate):
(WTF::LogChannels::clearAllLogChannelsToAccumulate):
(WTF::LogChannels::initializeLogChannelsIfNecessary):
(WTF::LogChannels::getLogChannel):

• wtf/LogChannels.h: Copied from Source/WebCore/platform/LogInitialization.h.

9:34 AM Changeset in webkit [280757] by commit-queue@webkit.org

• 34 edits
  6 deletes in trunk/Source

Unreviewed, reverting r280756.
​https://bugs.webkit.org/show_bug.cgi?id=228897

Broke gtk build

Reverted changeset:

"Deduplicate logging channel algorithms"
​https://bugs.webkit.org/show_bug.cgi?id=228809
​https://commits.webkit.org/r280756

12:54 AM Changeset in webkit [280756] by mmaxfield@apple.com

• 34 edits
  6 copies in trunk/Source

Deduplicate logging channel algorithms
​https://bugs.webkit.org/show_bug.cgi?id=228809

Reviewed by Fujii Hironori.

Source/WebCore:

No new tests because there is no behavior change.

• Sources.txt:
• WebCore.xcodeproj/project.pbxproj:
• accessibility/AXLogger.cpp:
• inspector/agents/page/PageConsoleAgent.cpp:
• page/Page.cpp:
• platform/LogInitialization.cpp: Copied from Source/WebCore/platform/LogInitialization.h.

(WebCore::logChannels):
(WebCore::getLogChannel):

• platform/LogInitialization.h:
• platform/Logging.cpp:

(WebCore::isLogChannelEnabled): Deleted.
(WebCore::setLogChannelToAccumulate): Deleted.
(WebCore::clearAllLogChannelsToAccumulate): Deleted.
(WebCore::initializeLogChannelsIfNecessary): Deleted.
(WebCore::getLogChannel): Deleted.

• platform/Logging.h:
• testing/js/WebCoreTestSupport.cpp:

(WebCoreTestSupport::setLogChannelToAccumulate):
(WebCoreTestSupport::clearAllLogChannelsToAccumulate):
(WebCoreTestSupport::initializeLogChannelsIfNecessary):

Source/WebKit:

• GPUProcess/GPUConnectionToWebProcess.cpp:
• GPUProcess/GPUProcess.cpp:

(WebKit::GPUProcess::initializeGPUProcess):

• Platform/LogInitialization.cpp: Copied from Source/WebKit/Shared/WebKit2Initialize.cpp.

(WebKit::logChannels):
(WebKit::getLogChannel):

• Platform/LogInitialization.h:
• Platform/Logging.cpp:

(WebKit::initializeLogChannelsIfNecessary): Deleted.
(WebKit::getLogChannel): Deleted.

• Platform/Logging.h:
• Shared/AuxiliaryProcess.cpp:

(WebKit::AuxiliaryProcess::initialize):

• Shared/WebKit2Initialize.cpp:

(WebKit::InitializeWebKit2):

• Sources.txt:
• UIProcess/WebPageProxy.cpp:
• UIProcess/WebProcessPool.cpp:
• WebKit.xcodeproj/project.pbxproj:
• WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::platformInitializeWebProcess):

Source/WebKitLegacy:

• WebKitLegacy.xcodeproj/project.pbxproj:

Source/WebKitLegacy/mac:

• Misc/WebKitLogInitialization.h: Copied from Source/WebKit/Platform/LogInitialization.h.
• Misc/WebKitLogInitialization.mm: Copied from Source/WebKitLegacy/mac/Misc/WebKitLogging.m.

(WebKit::logChannels):
(ReportDiscardedDelegateException):

• Misc/WebKitLogging.h:
• Misc/WebKitLogging.m:

(ReportDiscardedDelegateException): Deleted.

• WebCoreSupport/WebDragClient.mm:
• WebView/WebDelegateImplementationCaching.mm:
• WebView/WebView.mm:

(-[WebView _commonInitializationWithFrameName:groupName:]):

Source/WTF:

The current infrastructure (before this patch) had the following duplicated for each framework:

• A .cpp file declared the list of logging channels for that framework
• The .cpp file also had algorithms to search, modify, and initialize these logging channels

Each framework's .cpp file had duplicate algorithms. (The initialization algorithm was even
duplicated 3 times!)

Because the algorithms directly name their specific list of logging channels, a naive deduplication
would have had to add new parameters to these algorithms to pass in the appropriate framework's
list. That's fine, but this is exactly the sort of thing classes were designed for - classes are
an association of algorithms and data. The algorithms are shared but the data isn't, which really
just means we should have 3 instances of a shared class - one for the 3 sets of data.

So, this patch creates the LogChannels class which contains the deduplicated algorithms, and each
framework has a NeverDestroyed singleton instance of that class. There is a single virtual method
in the class, so the appropriate "default write" variable can be queried for each framework.

The instances cannot be declared in the Logging.h files in the frameworks, because certain WebKit2
files want to initialize all 3 instances of LogChannels, but you can't #include multiple Logging.h
files at the same time because their LOG_CHANNEL_PREFIX #defines will collide with each other.
Luckily, LogInitialization.h files exist exactly to solve this purpose, so that's where the
LogChannels instances are declared in. After this change, the Logging.h files are just for the
declarations of the logging channels themselves, and the LogInitialization.h files are for the
LogChannels instances which contain the searching/modifying/initializing algorithms on the list of
logging channels. If you just want to LOG(...) something, #include the relevant Logging.h file, and
if you want to search/modify/initialize across the entire list of channels, then #include the
relevant LogInitialization.h file.

• WTF.xcodeproj/project.pbxproj:
• wtf/CMakeLists.txt:
• wtf/LogChannels.cpp: Copied from Source/WebCore/platform/Logging.cpp.

(WTF::LogChannels::isLogChannelEnabled):
(WTF::LogChannels::setLogChannelToAccumulate):
(WTF::LogChannels::clearAllLogChannelsToAccumulate):
(WTF::LogChannels::initializeLogChannelsIfNecessary):
(WTF::LogChannels::getLogChannel):

• wtf/LogChannels.h: Copied from Source/WebCore/platform/LogInitialization.h.