bug fix(semantic): Validate quotient in const DivRem to avoid signed MIN/-1 ICE. - #10140
Conversation
…MIN/-1 ICE. The const-eval path for `DivRem::div_rem` stored the quotient without validating it against the input type's range. For signed `iN::MIN / -1` the quotient is `2^(N-1)` (= `iN::MAX + 1`), which is unrepresentable in `iN`; the out-of-range value was silently stored and later caused an ICE in sierra type-specialization (`Got failure while specializing type Const<i8, 128>`). Now the quotient is validated via `validate_literal`, emitting a clean E2008 LiteralError::OutOfRange — matching the `/` operator path. Fixes #10132. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This change is |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 4 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
PR SummaryLow Risk Overview Implementation uses Reviewed by Cursor Bugbot for commit 6eac831. Bugbot is set up for automated code reviews on this repo. Configure here. |
Summary
Adds overflow detection for signed integer
MIN / -1in constant evaluation. When evaluatingDivRem::div_remat compile time, the quotient is now validated against the target type's range usingvalidate_literal. If the quotient overflows (e.g.,-128_i8 / -1), a cleanE2008diagnostic is emitted instead of silently storing an out-of-range value that would later cause an ICE in sierra-gen. Thenum-integercrate is introduced to usediv_remfor computing both quotient and remainder together.Type of change
Please check one:
Why is this change needed?
For signed integers,
MIN / -1produces a quotient that overflows the type (e.g.,i8::MIN / -1 = 128, which exceedsi8::MAX). Previously, the constant evaluator would silently store this out-of-range value, which caused an ICE (internal compiler error) later during sierra code generation. The compiler should instead emit a clear, user-facing diagnostic at the point of the constant definition.What was the behavior or documentation before?
DivRem::div_rem(-128_i8, -1)in a constant expression would silently produce an out-of-range quotient value, leading to an ICE in sierra-gen rather than a proper compiler diagnostic.What is the behavior or documentation after?
DivRem::div_rem(-128_i8, -1)in a constant expression now emits:at the site of the offending expression, cleanly rejecting the invalid constant.
Related issue or discussion (if any)
N/A
Additional context
A test case (
DIVREM_SIGNED_MIN_OVERFLOW) has been added to the constant evaluation test data to cover this overflow scenario and verify the diagnostic output.