Fix new clippy lints #2429
Fix new clippy lints #2429
Conversation
Signed-off-by: ljedrz <[email protected]>
| @@ -186,7 +186,7 @@ impl<N: Network> RegisterTypes<N> { | |||
| for operand in async_.operands() { | |||
| if let Operand::Register(register) = operand { | |||
| if let Ok(RegisterType::Future(locator)) = register_types.get_type(stack, register) { | |||
| assert!(future_registers.remove(&(register.clone(), locator))); | |||
| assert!(future_registers.swap_remove(&(register.clone(), locator))); | |||
There was a problem hiding this comment.
we do want swap_remove here, because right after this loop we ensure that the future_registers is empty, meaning the order is no longer significant
There was a problem hiding this comment.
@d0cd @evan-schott can you confirm swap_remove is the intended behavior? (i understand it was technically swap_remove, want to ensure it truly shouldn't be shift_remove)
There was a problem hiding this comment.
Confirmed that swap_remove is intended since we do not rely on the order of future_registers after the removes are done.
| @@ -80,7 +80,7 @@ pub trait FromBytes { | |||
| } | |||
| } | |||
|
|
|||
| pub struct ToBytesSerializer<T: ToBytes>(String, Option<usize>, PhantomData<T>); | |||
| pub struct ToBytesSerializer<T: ToBytes>(PhantomData<T>); | |||
There was a problem hiding this comment.
Can you maybe share intuition or the clippy lint which led to these suggestions? The change ot FromBytesVisitor makes sense but for ToBytesSerializer and FromBytesDeserializer I don't see why we can remove those elements "for free" and why we put them there in the first place.
There was a problem hiding this comment.
clippy just stated that they are never used - I'm not sure why they were put there in the first place either (presumably some feature that was never added in the end), but everything still compiles just fine without them.
These pop up either when using some specific bits of snarkVM as a dependency or just start being detected in 1.77; regardless, they seem to be innocuous.
I found them by accident when using snarkVM as a dependency in a small benchmark binary.