pezkuwichain/pezkuwi-sdk
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix: Resolve cargo clippy errors and add CI workflow plan

Browse Source 
## Changes

### Clippy Fixes
- Fixed deprecated `cargo_bin` usage in 27 test files (added #![allow(deprecated)])
- Fixed uninlined_format_args in zombienet-sdk-tests
- Fixed subxt API changes in revive/rpc/tests.rs (fetch signature, StorageValue)
- Fixed dead_code warnings in validator-pool and identity-kyc mocks
- Fixed field name `i` -> `_i` in tasks example

### CI Infrastructure
- Added .claude/WORKFLOW_PLAN.md for tracking CI fix progress
- Updated lychee.toml and taplo.toml configs

### Files Modified
- 27 test files with deprecated cargo_bin fix
- bizinikiwi/pezframe/revive/rpc/src/tests.rs (subxt API)
- pezkuwi/pezpallets/validator-pool/src/{mock,tests}.rs
- pezcumulus/teyrchains/pezpallets/identity-kyc/src/mock.rs
- bizinikiwi/pezframe/examples/tasks/src/tests.rs

## Status
- cargo clippy: PASSING
- Next: cargo fmt, zepter, workspace checks
This commit is contained in:
Kurdistan Tech Ministry
2025-12-22 16:36:14 +03:00
parent 8acf59c6aa
commit 65b7f5e640
1393 changed files with 17834 additions and 179151 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/sdk/src/guides/async_backing_guide.rs
+7 -7
View File
@@ -99,8 +99,8 @@
//! }
//! ```
//!
//! 6. Update `pezsp_consensus_aura::AuraApi::slot_duration` in `pezsp_api::impl_runtime_apis` to match
//! the constant `SLOT_DURATION`
//! 6. Update `pezsp_consensus_aura::AuraApi::slot_duration` in `pezsp_api::impl_runtime_apis` to
//! match the constant `SLOT_DURATION`
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/apis.rs", impl_slot_duration)]
//!
//! 7. Implement the `AuraUnincludedSegmentApi`, which allows the collator client to query its
@@ -139,8 +139,8 @@
//! 1. Import `pezcumulus_primitives_core::ValidationCode` to `node/src/service.rs`.
#![doc = docify::embed!("../../templates/teyrchain/node/src/service.rs", pezcumulus_primitives)]
//!
//! 2. In `node/src/service.rs`, modify `pezsc_service::spawn_tasks` to use a clone of `Backend` rather
//! than the original
//! 2. In `node/src/service.rs`, modify `pezsc_service::spawn_tasks` to use a clone of `Backend`
//! rather than the original
//! ```ignore
//! pezsc_service::spawn_tasks(pezsc_service::SpawnTasksParams {
//! ..
@@ -224,9 +224,9 @@
//! 4. Update `MAXIMUM_BLOCK_WEIGHT` to reflect the increased time available for block production.
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/lib.rs", max_block_weight)]
//!
//! 5. Add a feature flagged alternative for `MinimumPeriod` in `pezpallet_timestamp`. The type should
//! be `ConstU64<0>` with the feature flag experimental, and `ConstU64<{SLOT_DURATION / 2}>`
//! without.
//! 5. Add a feature flagged alternative for `MinimumPeriod` in `pezpallet_timestamp`. The type
//! should be `ConstU64<0>` with the feature flag experimental, and `ConstU64<{SLOT_DURATION /
//! 2}>` without.
//! ```ignore
//! impl pezpallet_timestamp::Config for Runtime {
//! ..
docs/sdk/src/guides/enable_metadata_hash.rs
+4 -3
View File
@@ -44,8 +44,8 @@
//! ### Runtime integration
//!
//! From the runtime side only the
//! [`CheckMetadataHash`](pezframe_metadata_hash_extension::CheckMetadataHash) needs to be added to the
//! list of signed extension:
//! [`CheckMetadataHash`](pezframe_metadata_hash_extension::CheckMetadataHash) needs to be added to
//! the list of signed extension:
#![doc = docify::embed!("../../templates/teyrchain/runtime/src/lib.rs", template_signed_extra)]
//!
//! > **Note:**
@@ -76,7 +76,8 @@
//!
//! > **Note:**
//! >
//! > The `metadata-hash` feature needs to be enabled for the `bizinikiwi-wasm-builder` to enable the
//! > The `metadata-hash` feature needs to be enabled for the `bizinikiwi-wasm-builder` to enable
//! > the
//! > code for being able to generate the metadata hash. It is also recommended to put the metadata
//! > hash generation behind a feature in the runtime as shown above. The reason behind is that it
//! > adds a lot of code which increases the compile time and the generation itself also increases
docs/sdk/src/guides/enable_pov_reclaim.rs
+2 -2
View File
@@ -28,8 +28,8 @@
//! host function for this purpose. For convenience, pezcumulus provides
//! [`TeyrchainHostFunctions`](pezcumulus_client_service::TeyrchainHostFunctions), a set of
//! host functions typically used by pezcumulus-based teyrchains. In the binary crate of your
//! teyrchain, find the instantiation of the [`WasmExecutor`](pezsc_executor::WasmExecutor) and set the
//! correct generic type.
//! teyrchain, find the instantiation of the [`WasmExecutor`](pezsc_executor::WasmExecutor) and set
//! the correct generic type.
//!
//! This example from the teyrchain-template shows a type definition that includes the correct
//! host functions.
docs/sdk/src/guides/handling_teyrchain_forks.rs
+4 -4
View File
@@ -28,10 +28,10 @@
//! latency and reduces throughput, affecting the overall performance of the teyrchain.
//!
//! # Building on Older Pelay Parents
//! Pezcumulus offers a way to mitigate the occurence of forks. Instead of picking a block at the tip
//! of the relay chain to build blocks, the node side can pick a relay chain block that is older. By
//! building on 12s old relay chain blocks, forks will already have settled and the teyrchain can
//! build fork-free.
//! Pezcumulus offers a way to mitigate the occurence of forks. Instead of picking a block at the
//! tip of the relay chain to build blocks, the node side can pick a relay chain block that is
//! older. By building on 12s old relay chain blocks, forks will already have settled and the
//! teyrchain can build fork-free.
//!
//! ```text
//! Without offset:
docs/sdk/src/guides/your_first_node.rs
+1 -1
View File
@@ -103,9 +103,9 @@
mod tests {
use assert_cmd::assert::OutputAssertExt;
use cmd_lib::*;
use rand::Rng;
use pezsc_chain_spec::{DEV_RUNTIME_PRESET, LOCAL_TESTNET_RUNTIME_PRESET};
use pezsp_genesis_builder::PresetId;
use rand::Rng;
use std::{
io::{BufRead, BufReader},
path::PathBuf,
docs/sdk/src/guides/your_first_pallet/mod.rs
+36 -28
View File
@@ -42,8 +42,8 @@
//!
//! ### Shell Pezpallet
//!
//! Consider the following as a "shell pezpallet". We continue building the rest of this pezpallet based
//! on this template.
//! Consider the following as a "shell pezpallet". We continue building the rest of this pezpallet
//! based on this template.
//!
//! [`pezpallet::config`] and [`pezpallet::pezpallet`] are both mandatory parts of any
//! pezpallet. Refer to the documentation of each to get an overview of what they do.
@@ -59,18 +59,20 @@
//! issuance.
//!
//! > For the rest of this guide, we will opt for a balance type of `u128`. For the sake of
//! > simplicity, we are hardcoding this type. In a real pezpallet is best practice to define it as a
//! > simplicity, we are hardcoding this type. In a real pezpallet is best practice to define it as
//! > a
//! > generic bounded type in the `Config` trait, and then specify it in the implementation.
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", Balance)]
//!
//! The definition of these two storage items, based on [`pezpallet::storage`] details, is as follows:
//! The definition of these two storage items, based on [`pezpallet::storage`] details, is as
//! follows:
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", TotalIssuance)]
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", Balances)]
//!
//! ### Dispatchables
//!
//! Next, we will define the dispatchable functions. As per [`pezpallet::call`], these will be defined
//! as normal `fn`s attached to `struct Pezpallet`.
//! Next, we will define the dispatchable functions. As per [`pezpallet::call`], these will be
//! defined as normal `fn`s attached to `struct Pezpallet`.
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", impl_pallet)]
//!
//! The logic of these functions is self-explanatory. Instead, we will focus on the FRAME-related
@@ -143,16 +145,16 @@
//! Next, we create a "test runtime" in order to test our pezpallet. Recall from
//! [`crate::pezkuwi_sdk::frame_runtime`] that a runtime is a collection of pallets, expressed
//! through [`frame::runtime::prelude::construct_runtime`]. All runtimes also have to include
//! [`frame::prelude::pezframe_system`]. So we expect to see a runtime with two pezpallet, `pezframe_system`
//! and the one we just wrote.
//! [`frame::prelude::pezframe_system`]. So we expect to see a runtime with two pezpallet,
//! `pezframe_system` and the one we just wrote.
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", runtime)]
//!
//! > [`frame::pezpallet_macros::derive_impl`] is a FRAME feature that enables developers to have
//! > defaults for associated types.
//!
//! Recall that within our pezpallet, (almost) all blocks of code are generic over `<T: Config>`. And,
//! because `trait Config: pezframe_system::Config`, we can get access to all items in `Config` (or
//! `pezframe_system::Config`) using `T::NameOfItem`. This is all within the boundaries of how
//! Recall that within our pezpallet, (almost) all blocks of code are generic over `<T: Config>`.
//! And, because `trait Config: pezframe_system::Config`, we can get access to all items in `Config`
//! (or `pezframe_system::Config`) using `T::NameOfItem`. This is all within the boundaries of how
//! Rust traits and generics work. If unfamiliar with this pattern, read
//! [`crate::reference_docs::trait_based_programming`] before going further.
//!
@@ -164,12 +166,13 @@
//!
//! Another way to think about this is that within a pezpallet, a lot of types are "unknown" and, we
//! only know that they will be provided at some later point. For example, when you write
//! `T::AccountId` (which is short for `<T as pezframe_system::Config>::AccountId`) in your pezpallet,
//! you are in fact saying "*Some type `AccountId` that will be known later*". That "later" is in
//! fact when you specify these types when you implement all `Config` traits for `Runtime`.
//! `T::AccountId` (which is short for `<T as pezframe_system::Config>::AccountId`) in your
//! pezpallet, you are in fact saying "*Some type `AccountId` that will be known later*". That
//! "later" is in fact when you specify these types when you implement all `Config` traits for
//! `Runtime`.
//!
//! As you see above, `pezframe_system::Config` is setting the `AccountId` to `u64`. Of course, a real
//! runtime will not use this type, and instead reside to a proper type like a 32-byte standard
//! As you see above, `pezframe_system::Config` is setting the `AccountId` to `u64`. Of course, a
//! real runtime will not use this type, and instead reside to a proper type like a 32-byte standard
//! public key. This is a HUGE benefit that FRAME developers can tap into: through the framework
//! being so generic, different types can always be customized to simple things when needed.
//!
@@ -178,8 +181,8 @@
//!
//! ### Your First Test
//!
//! The above is all you need to execute the dispatchables of your pezpallet. The last thing you need
//! to learn is that all of your pezpallet testing code should be wrapped in
//! The above is all you need to execute the dispatchables of your pezpallet. The last thing you
//! need to learn is that all of your pezpallet testing code should be wrapped in
//! [`frame::testing_prelude::TestState`]. This is a type that provides access to an in-memory state
//! to be used in our tests.
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", first_test)]
@@ -191,8 +194,8 @@
//! This is why for example you see `Balances::<Runtime>::get(..)`. Finally, notice that the
//! dispatchables are simply functions that can be called on top of the `Pezpallet` struct.
//!
//! Congratulations! You have written your first pezpallet and tested it! Next, we learn a few optional
//! steps to improve our pezpallet.
//! Congratulations! You have written your first pezpallet and tested it! Next, we learn a few
//! optional steps to improve our pezpallet.
//!
//! ## Improving the Currency Pezpallet
//!
@@ -270,20 +273,20 @@
//! needing to re-execute the whole state transition function.
//!
//! With the explanation out of the way, let's see how these components can be added. Both follow a
//! fairly familiar syntax: normal Rust enums, with extra [`pezpallet::event`] and [`pezpallet::error`]
//! attributes attached.
//! fairly familiar syntax: normal Rust enums, with extra [`pezpallet::event`] and
//! [`pezpallet::error`] attributes attached.
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", Event)]
#![doc = docify::embed!("./packages/guides/first-pezpallet/src/lib.rs", Error)]
//!
//! One slightly custom part of this is the [`pezpallet::generate_deposit`] part. Without going into
//! too much detail, in order for a pezpallet to emit events to the rest of the system, it needs to do
//! two things:
//! too much detail, in order for a pezpallet to emit events to the rest of the system, it needs to
//! do two things:
//!
//! 1. Declare a type in its `Config` that refers to the overarching event type of the runtime. In
//! short, by doing this, the pezpallet is expressing an important bound: `type RuntimeEvent:
//! From<Event<Self>>`. Read: a `RuntimeEvent` exists, and it can be created from the local `enum
//! Event` of this pezpallet. This enables the pezpallet to convert its `Event` into `RuntimeEvent`, and
//! store it where needed.
//! Event` of this pezpallet. This enables the pezpallet to convert its `Event` into `RuntimeEvent`,
//! and store it where needed.
//!
//! 2. But, doing this conversion and storing is too much to expect each pezpallet to define. FRAME
//! provides a default way of storing events, and this is what [`pezpallet::generate_deposit`] is
@@ -315,7 +318,8 @@
//! - [`crate::reference_docs::defensive_programming`].
//! - [`crate::reference_docs::frame_origin`].
//! - [`crate::reference_docs::frame_runtime_types`].
//! - The pezpallet we wrote in this guide was using `dev_mode`, learn more in [`pezpallet::config`].
//! - The pezpallet we wrote in this guide was using `dev_mode`, learn more in
//! [`pezpallet::config`].
//! - Learn more about the individual pezpallet items/macros, such as event and errors and call, in
//! [`frame::pezpallet_macros`].
//!
@@ -603,7 +607,11 @@ pub mod pezpallet {
fn mint_works() {
StateBuilder::default().build_and_execute(|| {
// given the initial state, when:
assert_ok!(Pezpallet::<Runtime>::mint_unsafe(RuntimeOrigin::signed(ALICE), BOB, 100));
assert_ok!(Pezpallet::<Runtime>::mint_unsafe(
RuntimeOrigin::signed(ALICE),
BOB,
100
));
// then:
assert_eq!(Balances::<Runtime>::get(&BOB), Some(200));
docs/sdk/src/guides/your_first_runtime.rs
+7 -6
View File
@@ -49,10 +49,10 @@
//! their `Config` need to be implemented for `struct Runtime`:
#![doc = docify::embed!("./packages/guides/first-runtime/src/lib.rs", config_impls)]
//!
//! Notice how we use [`frame::pezpallet_macros::derive_impl`] to provide "default" configuration items
//! for each pezpallet. Feel free to dive into the definition of each default prelude (eg.
//! [`frame::prelude::pezframe_system::pezpallet::config_preludes`]) to learn more which types are exactly
//! used.
//! Notice how we use [`frame::pezpallet_macros::derive_impl`] to provide "default" configuration
//! items for each pezpallet. Feel free to dive into the definition of each default prelude (eg.
//! [`frame::prelude::pezframe_system::pezpallet::config_preludes`]) to learn more which types are
//! exactly used.
//!
//! Recall that in test runtime in [`crate::guides::your_first_pallet`], we provided `type AccountId
//! = u64` to `pezframe_system`, while in this case we rely on whatever is provided by
@@ -136,8 +136,9 @@
//! The implementation of these function can naturally vary from one runtime to the other, but the
//! overall pattern is common. For the case of this runtime, we do the following:
//!
//! 1. Expose one non-default preset, namely [`pezsp_genesis_builder::DEV_RUNTIME_PRESET`]. This means
//! our runtime has two "presets" of genesis state in total: `DEV_RUNTIME_PRESET` and `None`.
//! 1. Expose one non-default preset, namely [`pezsp_genesis_builder::DEV_RUNTIME_PRESET`]. This
//! means our runtime has two "presets" of genesis state in total: `DEV_RUNTIME_PRESET` and
//! `None`.
#![doc = docify::embed!("./packages/guides/first-runtime/src/lib.rs", preset_names)]
//!
//! For `build_state` and `get_preset`, we use the helper functions provide by frame: