fix: clippy

fix: clippy

fix: clippy

fix: clippy

fix: clippy

rust/constants/src/lib.rs

@@ -13,13 +13,13 @@
 //!
 //! - [`SPECSTREE`], with network specs in cold database format
 //! - [`VERIFIERS`], with network verifiers, i.e. data on who user trusts to
-//! sign updates for a given network
+//!   sign updates for a given network
 //! - [`METATREE`], with network metadata
 //! - [`ADDRTREE`], with user addresses public information
 //! - [`SETTREE`], containing general verifier, types information, and Vault
-//! danger status
+//!   danger status
 //! - [`TRANSACTION`], used to store temporarily transaction data while the
-//! user accepts or declines it
+//!   user accepts or declines it
 //! - [`HISTORY`], with history log
 //!
 //! Hot database contains following trees:
@@ -34,7 +34,7 @@
 //!
 //! - tree names in cold database alone or shared between cold and hot databases
 //! - key names in [`SPECSTREE`] tree of cold database alone or shared between
-//! cold and hot databases
+//!   cold and hot databases
 //! - recurring throughout the Vault seed phrase for Alice
 //! - QR graphic settings, used for both static and animated PNG QR codes
 //!
@@ -43,7 +43,7 @@
 //! air-gapped device. It includes:
 //!
 //! - keys for [`TRANSACTION`] tree, used for temporary storage for various
-//! kinds of transactions while they are shown to user for approval
+//!   kinds of transactions while they are shown to user for approval
 //! - display settings for history log and word guesser
 //!
 //! Feature `"active"` corresponds to all Vault-related things happening
@@ -54,7 +54,7 @@
 //! - default color settings for network specs
 //! - default files and folders name fragments, for use with `generate_message`
 //! - fountain qr generation parameters (large apng fountain qr codes are
-//! generated only on the hot side)
+//!   generated only on the hot side)
 //!
 //! Feature `"test"` includes all `"signer"` and `"active"` contents, and some
 //! recurring data for integration testing, such as known identicons and known

rust/db_handling/src/cold_default.rs

@@ -8,7 +8,7 @@
 //! - `HISTORY` with Vault history log
 //! - `METATREE` with network metadata
 //! - `SETTREE` with settings: types information, Vault dangerous exposures
-//! record and Vault database general verifier
+//!   record and Vault database general verifier
 //! - `SPECSTREE` with network specs
 //! - `TRANSACTION` for temporary storage of the transaction data
 //! - `VERIFIERS` with network verifiers data
@@ -19,10 +19,10 @@
 //! Before the database could be used, it must be initiated:
 //!
 //! - History log old entries (if any are present) are removed and a new entry
-//! `Event::DatabaseInitiated` is added
+//!   `Event::DatabaseInitiated` is added
 //! - General verifier is set and this event is recorded in the history log. By
-//! default, Vault sets up Parity-associated key as a general verifier. This
-//! could be later on changed by the user.
+//!   default, Vault sets up Parity-associated key as a general verifier. This
+//!   could be later on changed by the user.
 //!
 //! Vault then reads and updates the database as it operates.
 //!
@@ -31,13 +31,13 @@
 //! state. The difference would be only in the general verifier setting:
 //!
 //! - `Wipe all data` would set the general verifier to default `Some(_)`,
-//! with Parity-associated key inside
+//!   with Parity-associated key inside
 //! - `Remove general certificate` would set the general verifier to `None`.
-//! User would then be able to set up own general verifier, preferably
-//! immediately afterwards, by loading to Vault any verified data.
-//! Setting up a new general verifier would remove all data associated with the
-//! general verifier from the Vault database to avoid confusion as to who
-//! verified what information.
+//!   User would then be able to set up own general verifier, preferably
+//!   immediately afterwards, by loading to Vault any verified data.
+//!   Setting up a new general verifier would remove all data associated with the
+//!   general verifier from the Vault database to avoid confusion as to who
+//!   verified what information.
 #[cfg(feature = "active")]
 use parity_scale_codec::Encode;
 #[cfg(feature = "active")]

rust/db_handling/src/db_transactions.rs

@@ -498,8 +498,8 @@ impl TrDbColdStub {
     /// cold database:
     ///
     /// - Add a (key, value) pair to the metadata additions queue in
-    /// `metadata_stub`. Key is [`MetaKey`] in key form, value is metadata in
-    /// `Vec<u8>` format.
+    ///   `metadata_stub`. Key is [`MetaKey`] in key form, value is metadata in
+    ///   `Vec<u8>` format.
     /// - Add corresponding `Event::MetadataAdded(_)` into `history_stub`.
     pub fn add_metadata(mut self, meta_values: &MetaValues) -> Self {
         let meta_key = MetaKey::from_parts(&meta_values.name, meta_values.version);
@@ -515,7 +515,7 @@ impl TrDbColdStub {
     /// Prepare removing the metadata from the cold database:
     ///
     /// - Add [`MetaKey`] in key form to the metadata removals queue in
-    /// `metadata_stub`.
+    ///   `metadata_stub`.
     /// - Add corresponding `Event::MetadataRemoved(_)` into `history_stub`.
     ///
     /// Function is used for `Hold` and `GeneralHold` processing when,
@@ -532,26 +532,26 @@ impl TrDbColdStub {
     /// Prepare adding [`OrderedNetworkSpecs`] into the cold database:
     ///
     /// - Transform received in `add_specs` payload [`NetworkSpecs`]
-    /// into [`OrderedNetworkSpecs`] by adding `order` field. Networks are always added
-    /// in the end of the network list, with order set to the total number of
-    /// network specs entries currently in Vault. When a network is removed,
-    /// the order of the remaining networks gets rearranged, see details in
-    /// function [`remove_network`](crate::helpers::remove_network).
+    ///   into [`OrderedNetworkSpecs`] by adding `order` field. Networks are always added
+    ///   in the end of the network list, with order set to the total number of
+    ///   network specs entries currently in Vault. When a network is removed,
+    ///   the order of the remaining networks gets rearranged, see details in
+    ///   function [`remove_network`](crate::helpers::remove_network).
     /// - Add a (key, value) pair to the network specs additions queue in
-    /// `network_specs_stub`. Key is [`NetworkSpecsKey`] in key form, value is
-    /// SCALE-encoded [`OrderedNetworkSpecs`].
+    ///   `network_specs_stub`. Key is [`NetworkSpecsKey`] in key form, value is
+    ///   SCALE-encoded [`OrderedNetworkSpecs`].
     /// - Add corresponding `Event::NetworkSpecsAdded(_)` into `history_stub`.
     /// - Add root address for the network if the
-    /// [`AddressDetails`](definitions::users::AddressDetails) entry with
-    /// matching [`Encryption`](definitions::crypto::Encryption) already exists,
-    /// i.e. add (key, value) pair to the address additions queue in
-    /// `addresses_stub`. Key is
-    /// [`AddressKey`](definitions::keyring::AddressKey)
-    /// in key form, value is
-    /// SCALE-encoded updated
-    /// [`AddressDetails`](definitions::users::AddressDetails).
+    ///   [`AddressDetails`](definitions::users::AddressDetails) entry with
+    ///   matching [`Encryption`](definitions::crypto::Encryption) already exists,
+    ///   i.e. add (key, value) pair to the address additions queue in
+    ///   `addresses_stub`. Key is
+    ///   [`AddressKey`](definitions::keyring::AddressKey)
+    ///   in key form, value is
+    ///   SCALE-encoded updated
+    ///   [`AddressDetails`](definitions::users::AddressDetails).
     /// - If address was added, add corresponding `Event::IdentityAdded(_)`
-    /// into `history_stub`.
+    ///   into `history_stub`.
     ///
     /// Note that `add_network_specs` does not deal with network verifiers:
     /// verifier data is not necessarily updated each time the network
@@ -589,7 +589,7 @@ impl TrDbColdStub {
     /// Prepare removing [`OrderedNetworkSpecs`] from the cold database:
     ///
     /// - Add [`NetworkSpecsKey`] in key form to the network specs removal queue
-    /// in `network_specs_stub`.
+    ///   in `network_specs_stub`.
     /// - Add corresponding `Event::NetworkSpecsRemoved(_)` into `history_stub`.
     ///
     /// Function is used for `Hold` and `GeneralHold` processing when,
@@ -627,8 +627,8 @@ impl TrDbColdStub {
     /// database:
     ///
     /// - Add a (key, value) pair to the settings additions queue in
-    /// `settings_stub`. Key is [`GENERALVERIFIER`] and the value is
-    /// SCALE-encoded [`Verifier`] that is set to be the new general verifier.
+    ///   `settings_stub`. Key is [`GENERALVERIFIER`] and the value is
+    ///   SCALE-encoded [`Verifier`] that is set to be the new general verifier.
     /// - Add corresponding `Event::GeneralVerifierSet(_)` into `history_stub`.
     pub fn new_general_verifier(mut self, general_verifier: &Verifier) -> Self {
         self.settings_stub = self
@@ -644,8 +644,8 @@ impl TrDbColdStub {
     /// `load_types` update into the cold database:
     ///
     /// - Add a (key, value) pair to the settings additions queue in
-    /// `settings_stub`. Key is [`TYPES`] and the value is [`ContentLoadTypes`]
-    /// types information in `store` format (SCALE-encoded).
+    ///   `settings_stub`. Key is [`TYPES`] and the value is [`ContentLoadTypes`]
+    ///   types information in `store` format (SCALE-encoded).
     /// - Add corresponding `Event::TypesAdded(_)` into `history_stub`.
     pub fn add_types(mut self, types: &ContentLoadTypes, general_verifier: &Verifier) -> Self {
         self.settings_stub = self
@@ -676,9 +676,9 @@ impl TrDbColdStub {
     /// cold database:
     ///
     /// - Add a (key, value) pair to the verifiers additions queue in
-    /// `verifiers_stub`. Key is [`VerifierKey`] and the value is SCALE-encoded
-    /// [`ValidCurrentVerifier`] that is set to be the new verifier for the
-    /// network.
+    ///   `verifiers_stub`. Key is [`VerifierKey`] and the value is SCALE-encoded
+    ///   [`ValidCurrentVerifier`] that is set to be the new verifier for the
+    ///   network.
     /// - Add corresponding `Event::NetworkVerifierSet(_)` into `history_stub`.
     pub fn new_network_verifier(
         mut self,
@@ -748,9 +748,9 @@ impl Default for TrDbColdStub {
 /// - [`SignContent`] with data to sign
 /// - name of the network in which the transaction is made
 /// - derivation path of the address used, whether the address has password,
-/// corresponding [`MultiSigner`] value
+///   corresponding [`MultiSigner`] value
 /// - relevant history [`Event`] set: warnings that were shown during the
-/// parsing
+///   parsing
 #[derive(Debug, Decode, Default, Encode)]
 pub struct TrDbColdSign {
     /// Bulk of transactions to sign.
@@ -803,17 +803,17 @@ impl TrDbColdSign {
     /// Possible history log entries are:
     ///
     /// - `Event::TransactionSigned(_)` and `Event::MessageSigned(_)` for the
-    /// cases when the signature was generated and displayed through the user
-    /// interface
+    ///   cases when the signature was generated and displayed through the user
+    ///   interface
     /// - `Event::TransactionSignError(_)` and `Event::MessageSignError(_)` for
-    /// the cases when the user has entered the wrong password and no signature
-    /// was generated. Vault current policy is to log all wrong password entry
-    /// attempts.
+    ///   the cases when the user has entered the wrong password and no signature
+    ///   was generated. Vault current policy is to log all wrong password entry
+    ///   attempts.
     ///
     /// Required input:
     ///
     /// - `wrong_password` flag; for entries with `true` value the signature
-    /// was not generated, because user has entered the wrong password;
+    ///   was not generated, because user has entered the wrong password;
     /// - user-added text comment for the transaction
     /// - index of the transaction in the bulk
     /// - database name, into which the data is added
@@ -939,7 +939,7 @@ impl TrDbColdSignOne {
     /// - [`SignContent`] with data to sign
     /// - name of the network in which the transaction is made
     /// - derivation path of the address used, whether the address has password,
-    /// corresponding [`MultiSigner`] value
+    ///   corresponding [`MultiSigner`] value
     /// - relevant history [`Event`] set
     pub fn generate(
         content: SignContent,

rust/db_handling/src/error.rs

@@ -221,7 +221,7 @@ pub enum Error {
     ///
     /// Associated error content is:
     /// - [`MultiSigner`](https://docs.rs/sp-runtime/6.0.0/sp_runtime/enum.MultiSigner.html)
-    /// of the already existing address
+    ///   of the already existing address
     /// - [`AddressDetails`] for already existing address
     /// - [`NetworkSpecsKey`] of the associated network
     #[error(

rust/db_handling/src/helpers.rs

@@ -266,9 +266,9 @@ pub fn try_get_types(database: &sled::Db) -> Result<Option<Vec<TypeEntry>>> {
 /// Types data is expected to be found, for example, in:
 ///
 /// - hot database, from which the types data could not be removed using
-/// standard operations
+///   standard operations
 /// - cold database, when transactions made using `RuntimeMetadata` `V12` or `V13` are
-/// being decoded
+///   being decoded
 ///
 /// Not finding types data results in an error.
 pub fn get_types(database: &sled::Db) -> Result<Vec<TypeEntry>> {
@@ -455,9 +455,9 @@ pub fn transfer_metadata_to_cold(database_hot: &sled::Db, database_cold: &sled::
 /// Removing a network means:
 ///
 /// - Remove from [`SPECSTREE`] all [`OrderedNetworkSpecs`] that have genesis hash
-/// associated with given `NetworkSpecsKey`
+///   associated with given `NetworkSpecsKey`
 /// - Remove from [`METATREE`] all metadata entries corresponding to the network
-/// name, as found in `OrderedNetworkSpecs`
+///   name, as found in `OrderedNetworkSpecs`
 /// - Remove from [`ADDRTREE`] all addresses in the networks being removed
 /// - Modify `Verifier` data if necessary.
 ///

rust/db_handling/src/hot_default.rs

@@ -6,15 +6,15 @@
 //! Hot database contains following trees:
 //!
 //! - [`ADDRESS_BOOK`](constants::ADDRESS_BOOK) with information needed to
-//! perform RPC calls on networks
+//!   perform RPC calls on networks
 //! - [`METATREE`](constants::METATREE) with network metadata fetched through
-//! RPC calls, maximum two entries are allowed for each network, empty by
-//! default
+//!   RPC calls, maximum two entries are allowed for each network, empty by
+//!   default
 //! - [`META_HISTORY`](constants::META_HISTORY) with block hashes for metadata
-//! fetched through RPC calls, empty by default
+//!   fetched through RPC calls, empty by default
 //! - [`SETTREE`](constants::SETTREE) with types information
 //! - [`SPECSTREEPREP`](constants::SPECSTREEPREP) with network specs entries
-//! [`NetworkSpecs`](definitions::network_specs::NetworkSpecs)
+//!   [`NetworkSpecs`](definitions::network_specs::NetworkSpecs)
 use parity_scale_codec::Encode;
 use sled::Batch;
 

rust/db_handling/src/identities.rs

@@ -7,9 +7,9 @@
 //! Required data to generate address:
 //!
 //! - seed phrase (secret words set, must be always zeroized after use and is
-//! never stored in Rust database)
+//!   never stored in Rust database)
 //! - derivation path (`/soft//hard///password`); password part, i.e. whatever
-//! follows `///` is not stored in Rust database and must be zeroized after use
+//!   follows `///` is not stored in Rust database and must be zeroized after use
 //! - [`NetworkSpecsKey`](definitions::keyring::NetworkSpecsKey)
 //!
 //! The combination of seed phrase and derivation path allows to generate key
@@ -767,10 +767,10 @@ pub(crate) struct PrepData {
 /// The output [`PrepData`] contains:
 ///
 /// - `address_prep` set of `(AddressKey, AddressDetails)` values that
-/// eventually will be transformed into [`Batch`](sled::Batch) to update the
-/// `ADDRTREE` of the cold database
+///   eventually will be transformed into [`Batch`](sled::Batch) to update the
+///   `ADDRTREE` of the cold database
 /// - output `Event` set that will be eventually added into `HISTORY` as a part
-/// of single `Entry`(definitions::history::Entry)
+///   of single `Entry`(definitions::history::Entry)
 ///
 /// Function creates only **one** address, and output `PrepData` **updates**
 /// address preparation set received as input.
@@ -1003,10 +1003,10 @@ fn do_create_address(
 /// The output [`PrepData`] contains:
 ///
 /// - `address_prep` set of `(AddressKey, AddressDetails)` values that
-/// eventually will be transformed into [`Batch`](sled::Batch) to update the
-/// `ADDRTREE` of the cold database
+///   eventually will be transformed into [`Batch`](sled::Batch) to update the
+///   `ADDRTREE` of the cold database
 /// - output `Event` set that will be eventually added into `HISTORY` as a part
-/// of single `Entry`(definitions::history::Entry)
+///   of single `Entry`(definitions::history::Entry)
 ///
 /// All output `PrepData` elements are generated within this function.
 /// It does not input addresses previously processed for the same transaction
@@ -1464,7 +1464,7 @@ pub fn try_create_address(
 /// Function wipes [`ADDRTREE`] and adds:
 ///
 /// - seed key, i.e. seed addresses for all 3 default networks (Polkadot,
-/// Kusama, Westend)
+///   Kusama, Westend)
 /// - addresses with default derivation path in each default network
 /// - address with `//Alice` derivation path in Westend network
 #[cfg(feature = "active")]

rust/db_handling/src/lib.rs

@@ -6,11 +6,11 @@
 //!
 //! - contains helpers to operate the databases, used throughout Vault system
 //! - generates cold (used in air-gapped Vault) and hot (used in
-//! `generate_message` client) databases with default settings
+//!   `generate_message` client) databases with default settings
 //! - deals with taking data out of the database and putting the data in the
-//! database
+//!   database
 //! - contains Vault interface interactions, allowing exports of data to the
-//! interface
+//!   interface
 //! - deals with address generation for Vault
 //!
 //! # Features
@@ -67,7 +67,7 @@ use hot_default::reset_hot_database;
 ///
 /// - network specs for default networks (Polkadot, Kusama, Westend)
 /// - verifier information for default networks, with verifiers set to the
-/// general one
+///   general one
 /// - two latest metadata versions for default networks
 /// - default types information and clean danger status
 ///

rust/db_handling/src/manage_history.rs

@@ -145,7 +145,7 @@ pub fn history_entry_system(database: &sled::Db, event: Event) -> Result<()> {
 ///
 /// - Add history log entry with `Event::DeviceWasOnline`.
 /// - Update [`DangerRecord`] stored in [`SETTREE`](constants::SETTREE) with
-/// `device_was_online = true` flag.
+///   `device_was_online = true` flag.
 ///
 /// Unacknowledged non-safe [`DangerRecord`] block the use of Vault in the
 /// frontend.
@@ -164,7 +164,7 @@ pub fn device_was_online(database: &sled::Db) -> Result<()> {
 ///
 /// - Add history log entry with `Event::ResetDangerRecord`.
 /// - Reset [`DangerRecord`] stored in [`SETTREE`](constants::SETTREE) to
-/// `safe`, i.e. with `device_was_online = false` flag.
+///   `safe`, i.e. with `device_was_online = false` flag.
 ///
 /// Acknowledged and reset [`DangerRecord`] allow to resume the use of Vault in
 /// the frontend. Use it wisely.

rust/defaults/src/lib.rs

@@ -12,10 +12,10 @@
 //! Default build of the cold database for Vault includes:
 //!
 //! - general verifier `Verifier` set to `Some(VerifierValue)` with Parity
-//! public key as a verifier value
+//!   public key as a verifier value
 //! - network specs `OrderedNetworkSpecs` for default networks
 //! - verifiers for default networks, set to
-//! `CurrentVerifier::Valid(ValidCurrentVerifier::General)`
+//!   `CurrentVerifier::Valid(ValidCurrentVerifier::General)`
 //! - two latest metadata versions for each of the default networks
 //! - default types information
 //!