Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 808c74036a12ebbebfe06f899d2858b400d0f789
https://github.com/WebKit/WebKit/commit/808c74036a12ebbebfe06f899d2858b400d0f789
Author: Dan Hecht <[email protected]>
Date: 2026-08-24 (Mon, 24 Aug 2026)
Changed paths:
M Source/JavaScriptCore/b3/B3PureCSE.cpp
M Source/JavaScriptCore/b3/B3PureCSE.h
M Source/JavaScriptCore/b3/B3ReduceStrength.cpp
M Source/JavaScriptCore/b3/testb3.h
M Source/JavaScriptCore/b3/testb3_1.cpp
M Source/JavaScriptCore/b3/testb3_6.cpp
Log Message:
-----------
Cherry-pick [email protected] (353f0e1145bf).
https://bugs.webkit.org/show_bug.cgi?id=316347
[JSC] Fix B3 ReduceStrength Select specialization when a Check appears
between the Select and triggering Check
https://bugs.webkit.org/show_bug.cgi?id=316347
rdar://177687354
Reviewed by Marcus Plutowski.
In B3ReduceStrength, specializeSelect() specializes a Select that has a
constant
arm and is reached, within selectSpecializationBound, from a Check: it
splits the
block at the Check, clones the values between the Select and the Check into
the
then/else arms, and deleteValue()s the Void ones in that range.
PureCSE records pure Values in a per-iteration map (m_pureCSE) and assumes
they
stay present. Checks, though Void, are also recorded (to enable removing
redundant
Branches), so an intermediate Check in that range is recorded too;
specializeSelect
then deleteValue()s it without updating the map.
Keep the map consistent: remove the value from m_pureCSE before
specializeSelect
deletes it.
Tests: Source/JavaScriptCore/b3/testb3_1.cpp
Source/JavaScriptCore/b3/testb3_6.cpp
* Source/JavaScriptCore/b3/B3PureCSE.cpp:
(JSC::B3::PureCSE::clear):
(JSC::B3::PureCSE::remove):
* Source/JavaScriptCore/b3/B3PureCSE.h:
* Source/JavaScriptCore/b3/B3ReduceStrength.cpp:
* Source/JavaScriptCore/b3/testb3.h:
* Source/JavaScriptCore/b3/testb3_1.cpp:
(run):
* Source/JavaScriptCore/b3/testb3_6.cpp:
(testCheckSelectAndDeadCheckCSE):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.1114@webkitglib/2.52
Commit: e66f7ba8818f1c211a2f86cbfe4cf6d232842e56
https://github.com/WebKit/WebKit/commit/e66f7ba8818f1c211a2f86cbfe4cf6d232842e56
Author: Dan Hecht <[email protected]>
Date: 2026-08-24 (Mon, 24 Aug 2026)
Changed paths:
A JSTests/stress/operation-polymorphic-call-host-call-ic-reset.js
M Source/JavaScriptCore/bytecode/RepatchInlines.h
M Source/JavaScriptCore/jit/JITOperations.cpp
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
Log Message:
-----------
Cherry-pick [email protected] (09ca909b6a83).
https://bugs.webkit.org/show_bug.cgi?id=317142
[JSC] Do not attempt to link a CallLinkInfo after handleHostCall
https://bugs.webkit.org/show_bug.cgi?id=317142
rdar://178282225
Reviewed by Yusuke Suzuki.
handleHostCall performs the host call which may execute JS that
fires a watchpoint invalidating the passed CallLinkInfo. So,
it's not safe to modify *CallLinkInfo after the host call.
So, make the callers of virtualForWithFunction skip the
linkPolymorphicCall call in this case. This aligns the behavior
of operationPolymorphicCall / llint_polymorphic_call with linkFor.
However, to avoid the InternalFunction case potentially getting
stuck in the polymorphic mode slow path, return the JSCell in this case.
This is a slight change in behavior: before this change,
InternalFunction would have caused the CallLinkInfo to downgrade
to virtual mode. With this change, it can remain in polymorphic
mode. This also aligns with linkFor behavior.
Test: JSTests/stress/operation-polymorphic-call-host-call-ic-reset.js
* JSTests/stress/operation-polymorphic-call-host-call-ic-reset.js: Added.
(g2):
(g3):
(getP):
(evil.new.Proxy):
(evil.new.Proxy.apply):
* Source/JavaScriptCore/bytecode/RepatchInlines.h:
(JSC::virtualForWithFunction):
* Source/JavaScriptCore/jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_polymorphic_call):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.1115@webkitglib/2.52
Commit: d532453033db6ecd94418d3c5309fb31cd0dbb69
https://github.com/WebKit/WebKit/commit/d532453033db6ecd94418d3c5309fb31cd0dbb69
Author: Per Arne Vollan <[email protected]>
Date: 2026-08-24 (Mon, 24 Aug 2026)
Changed paths:
A
LayoutTests/fast/html/trusted-types-set-attribute-iframe-removal-crash-expected.txt
A
LayoutTests/fast/html/trusted-types-set-attribute-iframe-removal-crash.html
M Source/WebCore/dom/Attr.cpp
M Source/WebCore/dom/Element.cpp
Log Message:
-----------
Cherry-pick [email protected] (a26cf8dc190a).
https://bugs.webkit.org/show_bug.cgi?id=317320
Use-after-free of ScriptExecutionContext in trustedTypeCompliantString
https://bugs.webkit.org/show_bug.cgi?id=317320
rdar://177766868
Reviewed by Chris Dumez.
The method processValueWithDefaultPolicy can end up deleting the
ScriptExecutionContext passed as parameter.
This patch fixes this by adding protection of ScriptExecutionContext.
Test: fast/html/trusted-types-set-attribute-iframe-removal-crash.html
*
LayoutTests/fast/html/trusted-types-set-attribute-iframe-removal-crash.html:
Added.
*
LayoutTests/fast/html/trusted-types-set-attribute-iframe-removal-crash-expected.txt:
Added.
* Source/WebCore/dom/Attr.cpp:
(WebCore::Attr::setValue):
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::setAttribute):
(WebCore::Element::setAttributeNode):
(WebCore::Element::setAttributeNodeNS):
(WebCore::Element::setAttributeNS):
* Source/WebCore/dom/TrustedType.cpp:
(WebCore::trustedTypeCompliantString):
(WebCore::requireTrustedTypesForPreNavigationCheckPasses):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.1116@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/3cf0167134fd...d532453033db
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
