Disable legacy-arith by default in consensus/types#8695
Disable legacy-arith by default in consensus/types#8695mergify[bot] merged 6 commits intosigp:unstablefrom
legacy-arith by default in consensus/types#8695Conversation
pawanjay176
left a comment
There was a problem hiding this comment.
This LGTM, but it would be good if someone else can also take a look
| .saturating_sub(1u64); | ||
|
|
||
| if reqd_randao_epoch < state.min_randao_epoch() || epoch > state.current_epoch() + 1 { | ||
| if reqd_randao_epoch < state.min_randao_epoch() |
There was a problem hiding this comment.
Should also remove the allow lint in this file
There was a problem hiding this comment.
There are still some more #[allow(clippy::arithmetic_side_effects)] in beacon_state.rs and in validator.rs. Those seem a bit more involved to remove so I have left them for now
There was a problem hiding this comment.
Looks like this has been resolved except the ones in validator.rs?
There was a problem hiding this comment.
There is still the SSZ one in beacon_state.rs:
lighthouse/consensus/types/src/state/beacon_state.rs
Lines 3173 to 3174 in 8d72cc3
|
This pull request has merge conflicts. Could you please resolve them @macladson? 🙏 |
pawanjay176
left a comment
There was a problem hiding this comment.
LGTM. I'm fine with merging without handling the more involved allow lints see #8695 (comment).
Will wait for ✅ from @michaelsproul
|
Gonna go ahead and merge this one to avoid it going stale |
Merge Queue StatusRule:
This pull request spent 30 minutes 9 seconds in the queue, including 29 minutes 10 seconds running CI. Required conditions to merge
|
Issue Addressed
Currently,
consensus/typescannot build withno-default-featuressince we use "legacy" standard arithmetic operations.Proposed Changes
legacy-arithtosaturating-arithand disable it by default.Additional Info
We could consider removing support for standard arithmetic entirely, although I think having an opt-in feature which makes the dangers of enabling it clear is an okay solution for now, and won't break any external users (and our own
state_processingcrate).Incidentally, the ergonomics around using explicit methods such as
saturating_addwith integer types (which is available even withoutsaturating-arith) is a bit awkward, since it requires casting to u64 first.