mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-16 16:41:10 +00:00
Use same fmt and clippy configs as in Substrate (#7611)
* Use same rustfmt.toml as Substrate Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * format format file Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Format with new config Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Add Substrate Clippy config Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Print Clippy version in CI Otherwise its difficult to reproduce locally. Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Make fmt happy Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Update node/core/pvf/src/error.rs Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io> * Update node/core/pvf/src/error.rs Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io> --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io>
This commit is contained in:
committed by
GitHub
parent
ac435c96cf
commit
342d720573
@@ -30,10 +30,9 @@
|
||||
//! The versioning is achieved with the `api_version` attribute. It can be
|
||||
//! placed on:
|
||||
//! * trait declaration - represents the base version of the API.
|
||||
//! * method declaration (inside a trait declaration) - represents a versioned
|
||||
//! method, which is not available in the base version.
|
||||
//! * trait implementation - represents which version of the API is being
|
||||
//! implemented.
|
||||
//! * method declaration (inside a trait declaration) - represents a versioned method, which is not
|
||||
//! available in the base version.
|
||||
//! * trait implementation - represents which version of the API is being implemented.
|
||||
//!
|
||||
//! Let's see a quick example:
|
||||
//!
|
||||
@@ -90,14 +89,14 @@
|
||||
//! # How versioned methods are used for `ParachainHost`
|
||||
//!
|
||||
//! Let's introduce two types of `ParachainHost` API implementation:
|
||||
//! * stable - used on stable production networks like Polkadot and Kusama. There is only one
|
||||
//! stable API at a single point in time.
|
||||
//! * stable - used on stable production networks like Polkadot and Kusama. There is only one stable
|
||||
//! API at a single point in time.
|
||||
//! * staging - methods that are ready for production, but will be released on Rococo first. We can
|
||||
//! batch together multiple changes and then release all of them to production, by making staging
|
||||
//! production (bump base version). We can not change or remove any method in staging after a
|
||||
//! release, as this would break Rococo. It should be ok to keep adding methods to staging
|
||||
//! across several releases. For experimental methods, you have to keep them on a separate branch
|
||||
//! until ready.
|
||||
//! release, as this would break Rococo. It should be ok to keep adding methods to staging across
|
||||
//! several releases. For experimental methods, you have to keep them on a separate branch until
|
||||
//! ready.
|
||||
//!
|
||||
//! The stable version of `ParachainHost` is indicated by the base version of the API. Any staging
|
||||
//! method must use `api_version` attribute so that it is assigned to a specific version of a
|
||||
@@ -111,8 +110,8 @@
|
||||
//! ```
|
||||
//! indicates a function from the stable `v2` API.
|
||||
//!
|
||||
//! All staging API functions should use primitives from `vstaging`. They should be clearly separated
|
||||
//! from the stable primitives.
|
||||
//! All staging API functions should use primitives from `vstaging`. They should be clearly
|
||||
//! separated from the stable primitives.
|
||||
|
||||
use crate::{
|
||||
vstaging, BlockNumber, CandidateCommitments, CandidateEvent, CandidateHash,
|
||||
|
||||
Reference in New Issue
Block a user