pre-commit: update to match ci (#475)

.github/workflows/ci.yml

@@ -84,7 +84,7 @@ jobs:
           args: ${{matrix.args}}
 
   no-std:
-    name: build ${{matrix.toolchain}} no-std for wasm32-unknown-unknown 
+    name: build ${{matrix.toolchain}} no-std for wasm32-unknown-unknown
     runs-on: ubuntu-latest
     strategy:
       fail-fast: false

.pre-commit-config.yaml

@@ -21,12 +21,12 @@ repos:
     # Allows cargo fmt to modify the source code prior to the commit
     - id: cargo
       name: Cargo fmt
-      args: ["+stable", "fmt", "--all"]
+      args: ["+nightly", "fmt", "--all"]
       stages: [commit]
     # Requires code to be properly formatted prior to pushing upstream
     - id: cargo
       name: Cargo fmt --check
-      args: ["+stable", "fmt", "--all", "--check"]
+      args: ["+nightly", "fmt", "--all", "--check"]
       stages: [push, manual]
     - id: cargo
       name: Cargo check --all-targets
@@ -40,4 +40,7 @@ repos:
     # Unlike fmt, clippy will not be automatically applied
     - id: cargo
       name: Cargo clippy
-      args: ["+nightly", "clippy", "--workspace", "--", "--deny", "clippy::all", "--deny", "warnings"]
+      args: ["+nightly", "clippy", "--workspace", "--all-targets", "--", "--deny", "clippy::all", "--deny", "warnings"]
+    - id: cargo
+      name: Cargo clippy all-features
+      args: ["+nightly", "clippy", "--workspace", "--all-targets", "--all-features", "--", "--deny", "clippy::all", "--deny", "warnings"]

Makefile

@@ -12,4 +12,4 @@ test:
 fmt:
 	cargo +nightly fix --allow-staged --allow-dirty --all-targets --all-features
 	cargo +nightly fmt
-	cargo +nightly clippy --workspace --all-targets --all-features -- -D warnings
+	cargo +nightly clippy --workspace --all-targets --all-features -- -D warnings

docs/src/architecture.md

@@ -23,9 +23,9 @@ In Miden, there are accounts and notes which can hold assets. Accounts consume a
 [Assets](./architecture/assets.md) can be fungible and non-fungible. They are stored in the owner’s account itself or in a note. This chapter describes asset issuance, customization, and storage.
 
 ### Transactions
-[Transactions](./architecture/transactions.md) describe production and consumption of notes by a single account. Executing a transaction always results in a STARK proof. This chapter describes the transaction design and the implementation thereof. At it's core, transaction execution happens in the transaction kernel program which is explained in depth. 
+[Transactions](./architecture/transactions.md) describe production and consumption of notes by a single account. Executing a transaction always results in a STARK proof. This chapter describes the transaction design and the implementation thereof. At it's core, transaction execution happens in the transaction kernel program which is explained in depth.
 
-#### Accounts produce and consume notes to communicate 
+#### Accounts produce and consume notes to communicate
 <p align="center">
     <img src="./diagrams/architecture/miden_architecture_core_concepts.gif" style="width: 80%;">
 </p>
@@ -39,7 +39,7 @@ The state model captures all individual states of all accounts and notes. Finall
 ### Execution model
 [Execution](./architecture/execution.md) describes how the state progresses as aggregated state updates in batches, blocks, and epochs. This chapter describes the execution model and how blocks are built.
 
-#### Operators capture and progress state 
+#### Operators capture and progress state
 <p align="center">
     <img src="./diagrams/architecture/miden_architecture_state_progress.gif" style="width: 80%;">
 </p>
@@ -49,13 +49,13 @@ The state model captures all individual states of all accounts and notes. Finall
   <summary>Want to know more on why we designed Miden as is?</summary>
 
   ### Polygon Miden's architecture
-  Polygon Miden’s architecture departs considerably from typical blockchain designs to support privacy and parallel transaction execution. In traditional blockchains state and transactions must be transparent to be verifiable. This is necessary for block production and execution. User generated zero-knowledge proofs allow state transitions, e.g. transactions, to be verifiable without being transparent. 
+  Polygon Miden’s architecture departs considerably from typical blockchain designs to support privacy and parallel transaction execution. In traditional blockchains state and transactions must be transparent to be verifiable. This is necessary for block production and execution. User generated zero-knowledge proofs allow state transitions, e.g. transactions, to be verifiable without being transparent.
 
   ### Actor-based execution model
-  The actor model inspires Polygon Miden’s execution model. This is a well-known design paradigm in concurrent systems. In the actor model, actors are state machines responsible for maintaining their own state. In the context of Polygon Miden, each account is an actor. Actors communicate with each other by exchanging messages asynchronously. One actor can send a message to another, but it is up to the recipient to apply the requested change to their state. 
-  
-  Polygon Miden’s architecture takes the actor model further and combines it with zero-knowledge proofs. Now, actors not only maintain and update their own state, but they can also prove the validity of their own state transitions to the rest of the network. This ability to independently prove state transitions enables local smart contract execution, private smart contracts, and much more. And it is quite unique in the rollup space. Normally only centralized entities - sequencer or prover - create zero-knowledge proofs, not the users. 
+  The actor model inspires Polygon Miden’s execution model. This is a well-known design paradigm in concurrent systems. In the actor model, actors are state machines responsible for maintaining their own state. In the context of Polygon Miden, each account is an actor. Actors communicate with each other by exchanging messages asynchronously. One actor can send a message to another, but it is up to the recipient to apply the requested change to their state.
+
+  Polygon Miden’s architecture takes the actor model further and combines it with zero-knowledge proofs. Now, actors not only maintain and update their own state, but they can also prove the validity of their own state transitions to the rest of the network. This ability to independently prove state transitions enables local smart contract execution, private smart contracts, and much more. And it is quite unique in the rollup space. Normally only centralized entities - sequencer or prover - create zero-knowledge proofs, not the users.
 
   ### Hybrid state model
   The actor-based execution model requires a radically different approach to recording the system's state. Actors and the messages they exchange must be treated as first-class citizens. Polygon Miden addresses this by combining the state models of account-based systems like Ethereum and UTXO-based systems like Bitcoin and Zcash.
-</details>
+</details>

docs/src/architecture/accounts.md

@@ -17,7 +17,7 @@ In the above picture, you can see:
 * **Code →** a collection of functions which define the external interface for an account
 
 ### Account ID
-~63 bits (1 field element) long identifier for the account. The four most significant bits specify its [account type](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-types) - regular, immutable, faucet - and the [storage mode](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-storage-modes) - public or private. 
+~63 bits (1 field element) long identifier for the account. The four most significant bits specify its [account type](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-types) - regular, immutable, faucet - and the [storage mode](https://0xpolygonmiden.github.io/miden-base/architecture/accounts.html#account-storage-modes) - public or private.
 
 ### Account Storage
 Storage for user-defined data. `AccountStorage` is composed of two components.
@@ -44,7 +44,7 @@ Merkle tree as follows:
 An account vault can be reduced to a single hash which is the root of the Sparse Merkle Tree.
 
 ### Code
-Interface for accounts. In Miden every account is a smart contract. It has an interface that exposes functions that can be called by [note scripts](https://0xpolygonmiden.github.io/miden-base/architecture/notes.html#note-scripts) and [transaction scripts](https://0xpolygonmiden.github.io/miden-base/transactions/transaction-kernel.html#the-transaction-script-processing). Users cannot call those functions directly. 
+Interface for accounts. In Miden every account is a smart contract. It has an interface that exposes functions that can be called by [note scripts](https://0xpolygonmiden.github.io/miden-base/architecture/notes.html#note-scripts) and [transaction scripts](https://0xpolygonmiden.github.io/miden-base/transactions/transaction-kernel.html#the-transaction-script-processing). Users cannot call those functions directly.
 
 Functions exposed by the account have the following properties:
 
@@ -55,7 +55,7 @@ Functions exposed by the account have the following properties:
 *Note: Since code in Miden is expressed as MAST, every function is a commitment to the underlying code. The code cannot change unnoticed to the user because its hash would change. Behind any MAST root there can only be `256` functions*
 
 #### Example Account Code
-Currently, Miden provides two standard implementations for account code. 
+Currently, Miden provides two standard implementations for account code.
 
 ##### Basic user account (Regular updatable account)
 There is a standard for a basic user account. It exposes three functions via its interface.