Fix typed select pushing Type::Any instead of expected type#2707
Merged
Conversation
In OnSelect, when expected is non-empty (typed select instruction), the code validates type1 and type2 against expected[0] but never assigns result_type. It stays as Type::Any from initialization, defeating the purpose of the typed select which exists to provide precise type information for reference types.
Collaborator
|
This looks valid. Even without GC there are some reference types, so it is possible to add a test for this. With GC, unknown reference types in dead code could be an interesting test as well. |
Member
|
@zherczeg should we land this now or ask for a test for be added? |
Add a positive test verifying that typed select with funcref/externref annotations properly propagates the result type, allowing the result to be used in contexts expecting that specific reference type. Add a negative test verifying that using a typed select result where a different reference type is expected correctly produces a type mismatch error.
Contributor
Author
|
Added two tests:
|
sbc100
approved these changes
Feb 27, 2026
zherczeg
approved these changes
Feb 27, 2026
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
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
result_type, leaving it asType::Any.result_type = expected[0]in the typed select branch.Details
In
TypeChecker::OnSelect(type-checker.cc),result_typeis initialized toType::Any. The untyped select path (whenexpectedis empty) correctly setsresult_type = type1on line 1012. However, the typed select path (whenexpectedis non-empty) validates both operands againstexpected[0]but never assignsresult_type.The typed select instruction (
select t) exists specifically to provide precise type information for cases where the operand types alone are insufficient (e.g., reference types). PushingType::Anyas the result type defeats this purpose and can cause downstream type checking to be less precise than intended.The fix adds
result_type = expected[0]after the CheckType calls in the typed select branch, mirroring the pattern used in the untyped path.Tests
typed-select-result-type.txt: Verifies that typed select with funcref/externref annotations properly propagates the result type, allowing the result to be used in contexts expecting that specific reference type (e.g.,global.setto afuncrefglobal, return from anexternreffunction).bad-typed-select-type-mismatch.txt: Verifies that using a typed select(result funcref)whereexternrefis expected correctly produces a type mismatch error.