-
Notifications
You must be signed in to change notification settings - Fork 790
Fix parsing error on array.new_fixed on non-array #7604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -2213,6 +2213,9 @@ Result<> IRBuilder::makeArrayNewElem(HeapType type, Name elem) { | |||
|
|||
Result<> IRBuilder::makeArrayNewFixed(HeapType type, uint32_t arity) { | |||
ArrayNewFixed curr(wasm.allocator); | |||
if (!type.isArray()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this has to go here in IRBuilder? It doesn't look like the other allocation instructions have similar checks. I think we normally try to leave this for validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, the simpler constructors don't have that... I copied this from makeArrayInitElem
:
binaryen/src/wasm/wasm-ir-builder.cpp
Lines 2280 to 2282 in 2b89d33
if (!type.isArray()) { | |
return Err{"expected array type annotation on array.init_elem"}; | |
} |
Is that one also in the wrong place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, my guess is that we add these guards only when necessary to avoid assertion failures in ChildTyper. Is that what's happening here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that is the case. Without this PR, the crash is from IRBuilder, long before the validator,
(gdb) where
..
#5 in wasm::HeapType::getArray (this=0x7ffff15c3440) at binaryen/src/wasm/wasm-type.cpp:932
#6 in wasm::ChildTyper<wasm::IRBuilder::ChildPopper::ConstraintCollector>::visitArrayNewFixed (this=0x7ffff15c3360, curr=0x7ffff168c620) at src/ir/child-typer.h:947
#7 in wasm::Visitor<wasm::IRBuilder::ChildPopper::ConstraintCollector, void>::visit (this=0x7ffff15c3360, curr=0x7ffff168c620) at src/wasm-delegations.def:89
#8 in wasm::IRBuilder::ChildPopper::visitExpression (this=0x7ffff1461230, expr=0x7ffff168c620)
at binaryen/src/wasm/wasm-ir-builder.cpp:579
#9 in wasm::UnifiedExpressionVisitor<wasm::IRBuilder::ChildPopper, wasm::Result<wasm::Ok> >::visitArrayNewFixed (this=0x7ffff1461230, curr=0x7ffff168c620)
at src/wasm-delegations.def:89
#10 in wasm::Visitor<wasm::IRBuilder::ChildPopper, wasm::Result<wasm::Ok> >::visit (this=0x7ffff1461230, curr=0x7ffff168c620) at src/wasm-delegations.def:89
#11 in wasm::IRBuilder::visitExpression (this=0x7ffff1922130, curr=0x7ffff168c620) at binaryen/src/wasm/wasm-ir-builder.cpp:755
#12 in wasm::UnifiedExpressionVisitor<wasm::IRBuilder, wasm::Result<wasm::Ok> >::visitArrayNewFixed (this=0x7ffff1922130, curr=0x7ffff168c620)
at src/wasm-delegations.def:89
#13 in wasm::IRBuilder::makeArrayNewFixed (this=0x7ffff1922130, type=..., arity=1) at binaryen/src/wasm/wasm-ir-builder.cpp:2218
..
ChildTyper assumes the IR is valid enough for getArray to work, so we must check early.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, LGTM.
FYI the bad behaviour still happens with As far as I unsterstand it probably happens with all array operations. |
Thanks, all the related problems should be fixed by #7662. |
Fixes #7602