What changed, and why it matters
This commit adds a single Rust lint suppression to a macro that generates encoder helper types. It tells the Clippy static-analysis tool to stop complaining about overly complex types when nested encoders are combined. There is no functional code change, no bug fix, and no security relevance.
No security action required. Treat as a normal code-quality / CI hygiene change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change inserts #[allow(clippy::type_complexity)] on an impl block inside the encoder_newtype! macro in consensus_encoding/src/encode/mod.rs. The macro wraps an existing encoder in a newtype tuple that also carries a PhantomData lifetime marker. Combining encoders (e.g., Encoder6 + Encoder3 for a 9-field VersionMessage) produces nested tuple types that trigger Clippy’s type-complexity lint. The attribute suppresses that lint only; it does not alter generated code behavior, trait bounds, or public APIs.
Changed components
consensus_encoding/src/encode/mod.rsencoder_newtype! macroInspect captured patch +1 / −0
diff --git a/consensus_encoding/src/encode/mod.rs b/consensus_encoding/src/encode/mod.rs
index a0125736..d2c7f0cf 100644
--- a/consensus_encoding/src/encode/mod.rs
+++ b/consensus_encoding/src/encode/mod.rs
@@ -81,6 +81,7 @@ macro_rules! encoder_newtype {
$(#[$($struct_attr)*])*
$vis struct $name<$lt>($encoder, core::marker::PhantomData<&$lt $encoder>);
+ #[allow(clippy::type_complexity)]
impl<$lt> $name<$lt> {
/// Construct a new instance of the newtype encoder.
pub(crate) const fn new(encoder: $encoder) -> $name<$lt> {
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.