From 94aaf9c216e232bacde2764c65ee7e35caf09a0a Mon Sep 17 00:00:00 2001 From: rooooooooob Date: Wed, 18 Oct 2023 13:08:10 -0700 Subject: [PATCH] Fix CI cause by rust updating to 1.73 `clippy::incorrect_partial_ord_impl_on_ord_type` was failing. In a few cases this was fixed here, but others were coming from our use of the `derivative` crate causing clippy to think both were non-canonical implementations. Issue here for derivative: mcarton/rust-derivative#115 This was blanket ignored in cml-chain+cml-core to work around those. --- chain/rust/src/lib.rs | 12 ++++++++++++ core/rust/src/lib.rs | 12 ++++++++++++ crypto/rust/src/chain_crypto/digest.rs | 2 +- crypto/rust/src/chain_crypto/key.rs | 2 +- crypto/rust/src/lib.rs | 2 +- 5 files changed, 27 insertions(+), 3 deletions(-) diff --git a/chain/rust/src/lib.rs b/chain/rust/src/lib.rs index 8ee4f166..a8bef07a 100644 --- a/chain/rust/src/lib.rs +++ b/chain/rust/src/lib.rs @@ -1,3 +1,15 @@ +// This recently introduced lint does not play well with the derivative crate. +// We have both Ord and PartialOrd derive automatically by derivative's proc macros +// but clippy sees these as hand implementations. +// Putting this allow locally where it's found did not seem to supress it, +// likely due to the structure of how the proc macro derives the code. +// Doing what is suggested by this lint would just result in us actually doing +// hand implementations of the PartialOrd (an maybe PartialEq) when there's no need, +// possibly impacting PartialOrd performance on top of being unnecessary and occuring in generated code. +// Possibly the derivative crate could get updated to suppress this lint +// from within their proc macros itself. Issue: https://github.com/mcarton/rust-derivative/issues/115 +#![allow(clippy::incorrect_partial_ord_impl_on_ord_type)] + pub mod address; pub mod assets; pub mod auxdata; diff --git a/core/rust/src/lib.rs b/core/rust/src/lib.rs index 8428d49b..48886d15 100644 --- a/core/rust/src/lib.rs +++ b/core/rust/src/lib.rs @@ -1,3 +1,15 @@ +// This recently introduced lint does not play well with the derivative crate. +// We have both Ord and PartialOrd derive automatically by derivative's proc macros +// but clippy sees these as hand implementations. +// Putting this allow locally where it's found did not seem to supress it, +// likely due to the structure of how the proc macro derives the code. +// Doing what is suggested by this lint would just result in us actually doing +// hand implementations of the PartialOrd (an maybe PartialEq) when there's no need, +// possibly impacting PartialOrd performance on top of being unnecessary and occuring in generated code. +// Possibly the derivative crate could get updated to suppress this lint +// from within their proc macros itself. Issue: https://github.com/mcarton/rust-derivative/issues/115 +#![allow(clippy::incorrect_partial_ord_impl_on_ord_type)] + pub use error::*; pub mod error; diff --git a/crypto/rust/src/chain_crypto/digest.rs b/crypto/rust/src/chain_crypto/digest.rs index ab111f39..f6cbcd1b 100644 --- a/crypto/rust/src/chain_crypto/digest.rs +++ b/crypto/rust/src/chain_crypto/digest.rs @@ -337,7 +337,7 @@ impl Eq for DigestOf {} impl PartialOrd for DigestOf { fn partial_cmp(&self, other: &Self) -> Option { - self.inner.partial_cmp(&other.inner) + Some(self.cmp(other)) } } diff --git a/crypto/rust/src/chain_crypto/key.rs b/crypto/rust/src/chain_crypto/key.rs index 3545ab0a..eb4fd680 100644 --- a/crypto/rust/src/chain_crypto/key.rs +++ b/crypto/rust/src/chain_crypto/key.rs @@ -273,7 +273,7 @@ impl std::cmp::Eq for PublicKey {} impl std::cmp::PartialOrd for PublicKey { fn partial_cmp(&self, other: &Self) -> Option { - self.0.as_ref().partial_cmp(other.0.as_ref()) + Some(self.cmp(other)) } } diff --git a/crypto/rust/src/lib.rs b/crypto/rust/src/lib.rs index 77963b02..ca296f0d 100644 --- a/crypto/rust/src/lib.rs +++ b/crypto/rust/src/lib.rs @@ -478,7 +478,7 @@ macro_rules! impl_signature { impl PartialOrd for $name { fn partial_cmp(&self, other: &Self) -> Option { - self.0.as_ref().partial_cmp(other.0.as_ref()) + Some(self.cmp(other)) } }