Fix expected_type propagation for tuple-to-Array coercion in blocks#758
Merged
Fix expected_type propagation for tuple-to-Array coercion in blocks#758
Conversation
The associated constant pattern feature (Type::CONST in match/matches) is already implemented and all tests pass. Remove the stale TODO marker and outdated comment about parser rejection. https://claude.ai/code/session_01QJx35bRayRsECnakjUnGEN
…Wasm
The bug: when an if-else statement inside a match arm block returned
tuple literals (e.g. `[Pair { a: r, b: r }]`), the expected_type was
not propagated through, so the tuple-to-Array coercion via
SequenceLiteralBuilder never fired. This produced mismatched Wasm GC
types: `(ref (exact $type))` vs `(ref $type)`.
Root cause: `resolve_block` only propagated `expected_type` to the last
statement when it was `Stmt::Expr`, but if-else inside a match arm body
is parsed as `Stmt::If`. Added `resolve_if_stmt_with_expected` to
propagate expected_type through if statement blocks, and also propagate
expected_type through `Expr::Block` in `resolve_expr`.
https://claude.ai/code/session_01QJx35bRayRsECnakjUnGEN
The previous fix only handled Stmt::If in resolve_block. The same bug existed for Stmt::Match and Stmt::LabeledBlock as the last statement in a block: expected_type was not propagated, preventing tuple-to-Array coercion via SequenceLiteralBuilder. Also propagate expected_type through Expr::Block and Expr::LabeledBlock in resolve_expr for the same reason. https://claude.ai/code/session_01QJx35bRayRsECnakjUnGEN
Generated by on-task-done for the newly enabled test fixtures. https://claude.ai/code/session_01QJx35bRayRsECnakjUnGEN
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Array<Struct>from if-else producing invalid Wasm —resolve_blockonly propagatedexpected_typeto the lastStmt::Expr, but if-else/match/labeled-block as the last statement in a block are parsed asStmt::If/Stmt::Match/Stmt::LabeledBlock, so the tuple-to-Array coercion viaSequenceLiteralBuildernever fired, producing Wasm GC type mismatches ((ref (exact $type))vs(ref $type)).expected_typethrough all value-producing statement types (Stmt::If,Stmt::Match,Stmt::LabeledBlock) and expression types (Expr::Block,Expr::LabeledBlock).#![TODO]frommatch_associated_constant_pattern— the feature was already implemented; the TODO marker was stale.Test plan
on-task-donepasses (1278 tests, format, clippy, golden fixtures)https://claude.ai/code/session_01QJx35bRayRsECnakjUnGEN