fix(corelib): add /= and %= for i32/i64/i128 via non-deprecated *Assign - #10027
Conversation
i32/i64/i128 lacked DivAssign/RemAssign (only i8/i16 had the deprecated DivEq/RemEq that bridge to them). Add a non-deprecated `op_assign_by_op` helper deriving DivAssign/RemAssign from the binary Div/Rem ops, and instantiate it for i32/i64/i128. Add a regression test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This stack of pull requests is managed by Graphite. Learn more about stacking. |
PR SummaryLow Risk Overview A new Reviewed by Cursor Bugbot for commit 25db239. Bugbot is set up for automated code reviews on this repo. Configure here. |
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, and made 2 comments.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on orizi).
corelib/src/integer.cairo line 2662 at r1 (raw file):
impl I16AddEq = op_eq_by_op::AddEqImpl<i16>; impl I16SubEq = op_eq_by_op::SubEqImpl<i16>; impl I16MulEq = op_eq_by_op::MulEqImpl<i16>;
Consider also changing diveq to divassign in i8 and i16

Summary
Adds
DivAssign(/=) andRemAssign(%=) implementations fori32,i64, andi128signed integer types, which were previously missing. A newop_assign_by_opmodule is introduced to derive these assignment operators from their corresponding binary operators (DivandRem), mirroring the existingop_eq_by_oppattern.Type of change
Please check one:
Why is this change needed?
i8andi16had/=and%=operators, buti32,i64, andi128did not, creating an inconsistency across signed integer types.What was the behavior or documentation before?
Using
/=or%=oni32,i64, ori128values was not supported, while the same operators worked oni8andi16.What is the behavior or documentation after?
/=and%=are now supported uniformly across all signed integer types (i8,i16,i32,i64,i128). Tests cover division and remainder assignment for positive and negative values across all three newly supported types.Related issue or discussion (if any)
N/A
Additional context
The new
op_assign_by_opmodule is intentionally kept separate from the existingop_eq_by_opmodule to avoid using deprecated traits.