Merge pull request #5329 from tudorpintea999/tudorpintea999-fix-typos

fix: typos in the docs

CONTRIBUTING.md

@@ -64,7 +64,7 @@ Leo is a big project, so (non-)adherence to best practices related to performanc
 ### Memory handling
 - If the final size is known, pre-allocate the collections (`Vec`, `HashMap` etc.) using `with_capacity` or `reserve` - this ensures that there are both fewer allocations (which involve system calls) and that the final allocated capacity is as close to the required size as possible.
 - Create the collections right before they are populated/used, as opposed to e.g. creating a few big ones at the beginning of a function and only using them later on; this reduces the amount of time they occupy memory.
-- If an intermediate vector is avoidable, use an `Iterator` instead; most of the time this just amounts to omitting the call to `.collect()` if a single-pass iteraton follows afterwards, or returning an `impl Iterator<Item = T>` from a function when the caller only needs to iterate over that result once.
+- If an intermediate vector is avoidable, use an `Iterator` instead; most of the time this just amounts to omitting the call to `.collect()` if a single-pass iteration follows afterwards, or returning an `impl Iterator<Item = T>` from a function when the caller only needs to iterate over that result once.
 - When possible, fill/resize collections "in bulk" instead of pushing a single element in a loop; this is usually (but not always) detected by `clippy`, suggesting to create vectors containing a repeated value with `vec![x; N]` or extending them with `.resize(N, x)`.
 - When a value is to eventually be consumed in a chain of function calls, pass it by value instead of by reference; this has the following benefits:
   * It makes the fact that the value is needed by value clear to the caller, who can then potentially reclaim it from the object afterwards if it is "heavy", limiting allocations.

examples/auction/README.md

@@ -13,7 +13,7 @@ In this model, there are two parties: the auctioneer and the bidders.
 - **Bidder**: A participant in the auction.
 - **Auctioneer**: The party responsible for conducting the auction.
 
-We make following assumptions about the auction:
+We make the following assumptions about the auction:
 - The auctioneer is honest. That is, the auctioneer will resolve **all** bids in the order they are received. The auctioneer will not tamper with the bids.
 - There is no limit to the number of bids.
 - The auctioneer knows the identity of all bidders, but bidders do not necessarily know the identity of other bidders.

examples/basic_bank/README.md

@@ -13,14 +13,14 @@ This program implements a bank that issues tokens to users and allows users to d
 2. A user deposits tokens via the `deposit` function.
 3. Upon a user's request to withdraw, the bank calculates the appropriate amount of compound interest and pays the user the principal and interest via the `withdraw` function.
 
-Note that the program can be easily extended to include addition features such as a `transfer` function, which would allow users to transfer tokens to other users.
+Note that the program can be easily extended to include additional features such as a `transfer` function, which would allow users to transfer tokens to other users.
 
 ## Bugs
 
 You may have already guessed that this program has a few bugs. We list some of them below: 
 - `withdraw` can only be invoked by the bank. A malicious bank could lock users' tokens by not invoking `withdraw`.
 - `withdraw` fails if the sum of the interest and principal is greater than the user's balance. 
-- User's can increase their principal by depositing tokens multiple times, including immediately before withdrawl.
+- Users can increase their principal by depositing tokens multiple times, including immediately before withdrawal.
 - Integer division rounds down; if the calculated interest is too small, then it will be rounded down to zero.
 
 Can you find any others?