Fix panic when doing field access on numeric literals #9024
Conversation
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
When code like `1E10.e` is type-checked, the type system infers that
the number literal must have type `{ e: _ }` (a record with field `e`).
At runtime, the numeric literal evaluation functions (evalDec,
evalFracF64, evalFracF32) would use this inferred record layout, but
the record has size 0 (since the field is an unresolved flex var),
resulting in a null pointer. When field access was then attempted on
this "record", the code crashed with an assertion failure.
The fix adds layout compatibility checks to evalDec, evalFracF64, and
evalFracF32 similar to what evalNum and evalDecSmall already have.
When the inferred layout is not compatible with the literal type, we
fall back to the appropriate numeric layout (Dec, F64, or F32). This
allows the type checker to report a proper error message instead of
the interpreter crashing.
Fixes #9000
Co-Authored-By: Claude Opus 4.5 <[email protected]>
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
When code like
1E10.eis type-checked, the type system infers that the number literal must have type{ e: _ }(a record with fielde). At runtime, the numeric literal evaluation functions would use this inferred record layout, but the record has size 0 (since the field is an unresolved flex var), resulting in a null pointer. When field access was then attempted on this "record", the code crashed with an assertion failure.evalDec,evalFracF64, andevalFracF32similar to whatevalNumandevalDecSmallalready haveFixes #9000
Co-authored by Claude Opus 4.5