Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 1c34bb6fde435a9b659618f1589b00f59093ad79
https://github.com/WebKit/WebKit/commit/1c34bb6fde435a9b659618f1589b00f59093ad79
Author: Vassili Bykov <[email protected]>
Date: 2025-11-05 (Wed, 05 Nov 2025)
Changed paths:
A JSTests/wasm/regress/if-expr-type.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.h
M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp
Log Message:
-----------
Wasm FunctionParser should use the result type from the 'if' instruction
signature
https://bugs.webkit.org/show_bug.cgi?id=301707
rdar://162581991
Reviewed by Dan Hecht.
This patch addresses a problem that was exposed by
https://bugs.webkit.org/show_bug.cgi?id=297569.
After the change, BBQ emits null checks conditionally based on nullability of
the types
involved. That exposed an existing problem which may cause the nullability of
an `if`
expression to be determined incorrectly by the FunctionParser.
The failure scenario is illustrated by the included test. The `if` instruction
is declared
as producing a `RefNull($0)`. The `else` branch produces a `Ref($0)`, which
typechecks
because `Ref($0)` is a subtype of `RefNull($0)`. After processing the `if`
instruction,
the expression stack contains a TypedExpression of type `Ref($0)` left by the
`else`
branch. This is a problem because that expression now represents the entire
`if`, so the
type of `if` is incorrectly narrowed to the type of the `else` branch.
`array.init_data`
is then generated without a null check and fails when execution takes the
`then` branch
which produces a null reference.
The spec requires the result type of `if` to be the result type of the signature
associated with the `if`. This is illustrated by the `if`, `else`, and `end`
cases in
https://webassembly.github.io/spec/core/appendix/algorithm.html#validation-of-opcode-sequences.
The patch makes the following changes to implement the spec behavior:
- A new `BlockType::Else` value is introduced, to distinguish blocks following
an 'else'
instruction from other blocks. This is a useful distinction, present in the
spec algorithm
and already privately implemented by IPIntGenerator as the `isElse` field. The
field
in IPIntGenerator is removed because it's no longer necessary.
- `FunctionParser::unify` is renamed to a more specific `checkExpressionStack`.
The
function does not actually do any unification, and the original name
contributed to hiding the
problem of not joining the types of `if` branches.
- The renamed `FunctionParser::checkExpressionStack` is given an extra boolean
parameter
`forceSignature`. When its value is true, the types of values on the expression
stack are
replaced after a successful type check with types from the expected signature.
- Wasm parser uses the new parameter to replace types on the stack with
signature types
when processing an `end` instruction at the end of an `if-else`.
Test: JSTests/wasm/regress/if-expr-type.js
Canonical link: https://commits.webkit.org/302606@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
